Along the way I was able to test the iPad 2
to see if it would add value to the life of a designer/developer.
My goal was to find out whether I could increase my productivity by using an iPad (2) during my daily routine at work (meetings, workshops, drafting, coding). I wanted to find out if it makes sense during a meeting to scribble on the tablet and be done before I return to my office, if my team mates can collaborate (comment, enhance, brainstorm) with me faster and more efficient and overall if the little black gadget saves me time and energy.
My first objective was to install only free apps related to my field. This task alone turned out to be really cumbersome using the iStore. So I turned to the web and found plenty of nice blogs suggesting apps, some of these apps really powerful but other apps turned out to have switched to (outrageous) paid mode.
Next I looked into paid apps and the possibility to snatch a free trial by contacting their customer service. NO WAY JOSE. I was turned down with the argument that iStore controls the distribution of the apps and doesn't allow free trials - what a downer!! Can anybody confirm this? Are there alternatives I haven't thought of?
Thirdly I installed apps that I though might be useful for general tasks like note-taking, document sharing, etc.
I started bringing the little black gadget to meetings and started playing around with it during breaks. Whenever I saw a colleague with an iPad I asked for their experiences using it in a professional setting.
I installed the following apps:
Description: Any of the following types can be stored as 'notes': Browser, Canvas, Calculator, Note, Tasks, Map
Features: Share by email, save to photo library, publish to posterous or dropbox
Facit: really useful
Description: tool to create mockups very similar to Balsamiq (that I use)
Features: share by email and then export to balsamiq
Facit: no import from balsamiq in free version
Description: sketch anything on a map and let the map use this as the area of interest and show restaurant choices
Facit: not really a productivity tool, but i was intersted to see it because a map was involved
Description: sketch simple to complex geometries
Facit: didn't quite see the use of it in our workflows
GoToMeeting & TeamViewer
Description: both are meeting/sharing applications and very useful
Facit: nothing that the laptop couldn't do
To Do's Lite
Description: Create todo lists
Facit: didn't see how to share/sync this list, ads are ok, not really distracting and if it helps to pay a free version I'm fine with it
Description: nice todo list organizer
Features: see your own 'notebook' or your friend's, sync with your email account or share via facebook/twitter
Facit: good organizer
Paving the cowpath
I was invited to help with some open design questions for a beta version of a product, a prototype already existing.
The question on hand is fairly simple, how can we visually show the quality of the data (in the grid) to the user? Should we use green up arrows and red down arrows (two symbols)? green, yellow (kind of not sure marker), red checkmarks/crosses (3 symbols)? Percentages? A, B, C, D, F (like the US school system, with F is Fail but the others show grades of good quality, 5 symbols)? The latter was tossed out immediately after having three different school systems sitting at the table (Spain, India, Austria).
So I found myself in a situation where a single requirement started to explode into a universe of great ideas and variants that the team of developers tried to incorporate as they popped up. I tried to keep up with mocking up in my mind what I thought fit. Every new take promised greatness but required compromise somewhere else.
The Turning Point
Only when the discussion started to run in circles I felt it was necessary to step up. I was in a dilemma, I knew a decision had to be made and I knew also that it was up to me to speak out. So I said...
"Let's keep it simple" - Ha, you could have come up with that too, right? Well, what I really said was: "Let's don't do anything and let the users complain that they are missing something." Or in other words, let's pave the cowpath.
So we decided to include 1 symbol, the red flag, to show the bad items, no other item will be marked, neither the good ones nor the one within a threshold between good and bad. Let's sit and wait to receive feedback that what we assume we might need is actually needed.
What would you have done?
Recipe for success
In a large bowl, add the original user need. Stir in business strategy, market and technology opportunities. Add a pinch of sponsor-, cost-, and lifespan-considerations. Bring to a boil, then reduce heat. Let it simmer for 1-3 sketch iterations, or until mockups thicken. Season with images, jQuery animations, and cascading stylesheets. Bake in pre-heated development environment until golden brown. Serve while still hot.
Example for an ellipsed command
As traditional web pages morph more and more into web applications, it also becomes more important to understand and properly use elements that originated on the desktop.
Just recently I found myself in the middle of a design meeting - and you know how that goes, mostly opinionated programmers 😉 - talking about the latest mockups. So somebody said, and probably rightly so, that our menus and command buttons should have ellipses like any Microsoft-esque app.
A fierce discussion started, not IF we should do it, but rather HOW and WHEN we should do it.
So WHEN should we use ellipses?
Quickly the general opinion became: "whenever an action displays another window". Like in a flash of genius I refused to make up standards and promised to do some homework research. And sure enough, above statement is incorrect like the Windows UX Interaction Guidelines from Microsoft state on page 236:
Indicate a command that needs additional information (including a confirmation) by adding an ellipsis at the end of the label.
Menu commands are used for immediate actions, but some actions need additional input and require the user to make further choices before performing the action - that's when the use of ellipses is important to provide visual cues of this fact upfront.
Do NOT use ellipses only because the action triggers a new window. Prominent examples are "About", "Advanced", "Help", "Options", "Properties", or "Settings". The all display another window when clicked, but don’t require additional information from the user. Therefore they don’t need ellipses.
Cases of ambiguity
The document states that there might be cases of ambiguity, e.g. if the command label lacks a verb that describes the action.
In the first example, users are most likely going to choose a color, so using an ellipses is correct.
In the second example, users are most likely going to view the version information, making ellipses unnecessary.
In case of ambiguity decide based on the most likely user action.