[ This is an article I wrote for my design students, but is just as applicable to the professional world. ]

As part of any design related activity, you are expected to contribute and participate in design discussions by offering constructive feedback to your peers.  It is important to not only be able to design your own work, but contribute to others’ designs.  In the professional world, you will be expected to offer constructive feedback to your team members and clients. Learning to offer feedback, and to offer it (as well as receive it) in a constructive manner is an important skill to master and will ensure that your feedback will not be received a just junk.

Your goal with feedback is not to embarrass your peers by pointing out their flaws, but to give them ways to improve in a positive tone.  Remember that you are trying to help, not hurt. Therefore the way you communicate your message is important.  When communicating negative feedback, you must do so in a constructive fashion.

The main way to do this is to avoid coloring your feedback with emotion.  For example, instead of saying “Your work is terrible”, you should say “The readability of your site could be improved by using a larger font”. This provides a constructive solution, not just pointing out the problem.

The same goes for positive feedback.  Just saying “Your work is great” does not help anyone improve.  While it may feel good in the short term, we are all looking to learn and no one can learn if this is all the feedback you provide. Instead, explain WHY their work is great, such as “Your work is great because your site’s navigation makes it really easy to get around.”  Providing this type of feedback not only makes your peer feel good, but it provides them insight as to what they’ve done right so they can continue to do so in the future.

It is also important to be able to learn to accept feedback as well. And keep in mind that not all your peers (and usually your boss) will have read this article. Not all feedback you receive will be presented this nicely. In these cases, you should learn to strip away the emotion and just get at the constructive portion.  If a peer presents you with feedback that is too “emotional”, learn to ask them “Why” so you can get at the root of the problem.

Tips:

- Avoid emotions: Avoid coloring your feedback with your feelings. Don’t just rant, but explain why.
- Soften the blow: When presenting negative feedback, always include some positive feedback to help soften the blow. Don’t make things up or “sugar coat” things unnecessarily, but show your peer that you recognize the positive things they’ve done as well.
- Double Check: Re-read your feedback and before submitting, ask yourself how you would feel if you received this same feedback.

Questions?

I love Google Search because when I search for something, there’s some magic Fortune Teller that Google has locked up in a server room somewhere that knows exactly what I’m looking for.

So I was excited by the recent launch of Google Suggest, the new auto-complete on Google’s home page. As you start type, Google’s servers are busy finding and returning related search terms. This is a great idea, but the results don’t seem nearly as precise as I’ve come to expect from Google. I’m guessing the Fortune Teller does better when responding to full terms than to just a few letters.

My suggestion for making these results more on target is to personalize them. Google knows my search history, and the types of things I search for. Therefore they should be able to give me better responses in Google Suggest.

This is noticeably missing because I’m used to using the Google Search box built into Firefox. This search box has an auto-complete which includes both my recent search terms (at the top) and other matching (non-personalized) results below. While only the top part of the list is personalized, the top matches have been valuable enough that I will continue to use this over Google Suggest.

One side effect of implementing this sort of functionality is that the more personalized your results become, the less diverse they might be. But I’m sure the genius’ at Google can figure this out too.

Well, I’ve been playing with my iPhone for about a week now, and am impressed overall. Its great as a phone and simple PDA, but the rest of the “productivity” functionality is way behind the times. Most of the issues I’ve found result from the core functional design that cannot be changed (or can only by partially solved) by third party applications.

Granted, its a phone first, and computer second, but my last phone (Palm Treo 700p) seemed to do the job just fine. Despite the smaller screen and less glamour, I felt the Treo was more capable in two big areas (for me):

• Data Storage: Both the Treo, as well as all previous iPods, had the capability of being mounted as a hard drive over USB (and SD Reader). This saved me from having to carry an extra USB/Flash/Thumb Drive. While that’s only a few ounces, the bigger result here is that this problem trickles through all the iPhone applications. This means that (except as read-only) there are no email attachments, web downloads/uploads, and any third party app that would need access to documents (such as an eBook reader) must provide its own proprietary uploader (or web storage). Granted, there are a few third party apps that try to solve this by either mounting over WiFi (DataCase), Web (SugarSync, MiGhtyDocs), or a proprietary uploader (FileMagnet). My testing of all of these solutions shows them as very slow and fairly buggy. Enough to where I would not trust using these as the primary store for a few gigs of documents. Not to mention that they don’t solve the root problem here because the documents are only available in the restricted sandbox of that single application. While Apple has not commented on the reasons behind disabling this functionality, my gut tells me that resource priorities and security concerns have taken precedence over usability. Hopefully over time Apple can provide a solution.

• Office Suite: A sibling to the above problem is that the iPhone does not have an Office Suite. There is no mobile version of Office/iWork/etc. The iPhone does have the capability (and plenty of sandboxed Apps) to display these documents when found in web pages or the third party apps listed above, but cannot edit them. Granted, you would probably not do your main editing on the small screen, but I definitely used my Treo often for touch-up work while on the road. I’ve used the Treo to make last minute changes to Powerpoint presentations, my resume, or Word Doc proposals, etc. This deficiency is visible in both native iPhone Apps and Safari, neither of which support even basic rich text editing (I take lots of notes as RTF’s in TextEdit). Again, I’m guessing that the cost outweighs the benefits for Apple here, but for me this is a big thing.

These issues hit me pretty hard today because I’m off on a quick 1 day business trip this afternoon, and although I won’t need my laptop during my meetings, I’m forced to lug it around just to review a few PDF’s, DOC’s, CHM’s, as well as review and update my RTF notes. I can probably find a combination of various iPhone apps to handle my needs (if i convert my notes to plain text), but I don’t have the time and have come to expect Apple technology to “just work” and not require all these “band-aid” solutions. (And I shouldn’t have to buy yet another device or mini laptop to do this.)

Well, after pretty much everything going wrong dealing with AT&T for around a total of 8 hours in phone support or in store, I finally got my iPhone up and running on Friday, and here’s my take after the first weekend. I’ll try not to repeat everything that has been said already, other than to summarize that the iPhone is great however the battery and 3G network are laughable.

But I did want to do a quick write up to discuss some technology vs. design experiences so far. I give Apple alot of credit for the simple and intuitive interfaces used in the iPhone (and iTunes to manage it on your computer). I’ve got some issues with over-simplicity here, but I’ll save that for another post.

For now, I wanted to discuss a few things I found while building my first iPhone App. Now, I started out easy and just built a web-based Safari app (to get a quick start) rather than learning the native application SDK (which I’ll tackle next). If you’re not familiar with iPhone web-app development, there’s a great User Interface library (iUI from Facebook’s Joe Hewitt) which developers can easily implement to simulate most of the iPhone’s capabilities in Safari.

So I grabbed iUI, and threw together a quick application to show each DC Metro Station’s next train arrival time. I figured this would be very handy for me when I’m on the go to see how much I have to rush (or stall) to get the next train. The basics are working if you want to check it out (on your iPhone) over at metro.orangewiz.com, however I can’t guarantee this will be speedy or stay up (or even stay there) permanently.

The major issue I found with the iUI interface is that it is AJAX-based by default. If you’re not familiar with this, AJAX basically means that data chunks (and in this case full pages) are loaded into the current page without having to reload the whole current page. This is great for many things, such as the new Google Suggest which is basically an “auto-complete” that loads and displays related search terms as you type in the search box. However, AJAX has some real disadvantages when not used properly.

In iUI, AJAX is used to simulate the iPhone’s “sliding screen” feature (seen in the first few seconds of this video) to fully load the next page and animate it sliding in over the current page when you click forward. This is some great eye candy, but is not very practical for my application. Loading the next page into the current page (without actually changing pages) means you can’t bookmark anything. In my App, I really need to be able to bookmark my home metro station that I use most often, rather than having to navigate through all the stations from scratch. Luckily, iUI lets you override this default behavior to deliver bookmarkable (but non-sliding) pages. (Techie info: use “target=_self” to bypass the AJAX swipes.)

In most cases, my recommendation would be to only use AJAX to alter small individual components within a page, rather than loading in full pages. Of course, there are places where AJAX on a larger scale makes sense, but only when your users will not have to repeatedly navigate through a maze of links to get to content they will access frequently. Google Maps is one example where almost the entire page is AJAX so that you don’t have to reload a full new map just to scroll around. In this case, this provides so much of an advantage over the alternative that its worth it. And Google is smart enough to provide a “Link” option in the upper right hand corner where you can Copy/Paste (and therefore bookmark) a link that will bring you back to the exact same spot on the map.

Lesson here: Just because you’ve got the technology to do something, doesn’t mean you should do it. Just because its “slick” doesn’t mean its usable. You need to take into account what the impact on your Users/Customers will be and how that technology can be used as a benefit, rather than a hindrance to them.