(Just to be clear, that is their default hint text - I didn't type it.)
(Just to be clear, that is their default hint text - I didn't type it.)
Excerpts from a JIRA article I wrote at work.Make system status and feedback clear and visible
Present information with meaningful aids to interpretation
Use words, phrases and concepts familiar to users - don't use 'programmer speak'. Use everyday terms, or familiar frameworks.
Help users recognise, diagnose and recover from or resolve errors
Give users a "way out" when they make mistakes (e.g. cancel). Where Undo/Redo is not possible or viable, present users with solutions.
E.g. The supplier record could not be deleted because transactions have been made against it. <Deactivate Supplier Record> <Cancel>
Use clear, consistent language, and names/labels that are conceptually related to their functions
Standardise language across your platform. If 'Cancel' means 'Exit without implementing any changes' in one context, it should mean that in all contexts. Whenever possible, button labels should be specific, rather than generic. (e.g. 'Save & Exit' vs 'Okay').
Help users not to make mistakes
Present users with a confirmation before they commit to an action with serious and/or irrevocable consequences. In such cases, it's a good idea to place the Commit and Cancel buttons far apart to prevent users clicking the wrong buttons by mistake. If keyboard controls are in play, require the users to either click the (far apart) buttons, or to commit by pressing a specific key or key combination, rather than tab-Entering.
Display only the information a user needs to complete a discrete task at a given time
Don't make users remember information from one part of the dialogue to another, and don't pepper them with information irrelevant to the task at hand.
Make the right things invisible
Automate and/or hide tasks/functions users have no control over, but that the platform requires to work.
Group information consistently and meaningfully
Don't make users search and mix-n-match information from all over your page if what they're looking for falls into an identifiable group. (E.g. Address, Mobile, Fax..)
Reduce user workload & set meaningful defaults
Pre-populate standard fields whenever possible and/or helpful. Base defaults on choices that the majority of users would make. Default settings should make things easier on the standard user, not harder.
This list was based on Jakob Nielsen's heuristics as published in Usability Engineering, Jill Gerhardt-Powals' work in Human Computer Interaction (paid link), and Bruce Tognazzini's First Principles of Interaction Design.
While every engineer may find Search easy and efficient, that is not the experience of most people under many conditions, including those encountered by the users of the systems Craig has referenced—Contacts, iOS, and Lion. Learning to type into a box is easy. Memorizing the names of perhaps several hundred apps so you know what to type into the box, not so easy. Unless you are an engineer.
Graphic designers, left unchecked and unschooled, are likely to aim for maximum visual simplicity at the expense of both learnability and usability. Such interfaces require users to discover new capabilities by clicking around and seeing what happens. Users don't do that.
So much good stuff in here! The second quote about graphic designers, in particular, sounds like what I spent the first 3+ years when I started working in the digital space arguing against, usually on the losing side.
Responsive design is more work. And more expensive. Maybe you don't need it as much as you think you do.
I've run into the idea that since responsive design is a more efficient mobile solution than creating unique mobile sites or alternate page templates, it is therefore going to be cheaper and simpler than what everyone is expecting. Not true. The fact of the matter is that doing responsive design requires work that just wouldn't be done at all if mobile wasn't a consideration. Now, I'm not advocating that we ignore mobile. But in some cases, I'd argue that mobile is probably higher on the priority list than a serious cost/benefit analysis would merit.
Our audience is primarily comprised of people working in the advertising, marketing and design industry. They're people who influence or make decisions about design and development projects. With our audience in mind, if you were to ask me if mobile should be a higher priority I'd say absolutely. I'd think of all of our hip and stylish visitors and how many of them probably already have an iPhone 5. But you know what? In the last month, just under 10% of our website's visitors accessed it with a mobile device. That includes phones and tablets. If I extend my look to the last six months, the mobile population is exactly the same. The last year? It drops to 8%. So, mobile traffic is growing, but not as rapidly as I would have assumed based upon what I think I know about our audience. With those numbers, should mobile be prioritized as much as it has been (we're about to launch a site redesign that makes heavy use of responsive design techniques — more on that later)? With over 90% of our visitors still coming in through a "desktop" computer? Probably not. But for us, there's an additional consideration of needing to demonstrate our capabilities in this area, which pushes the benefits over the cost. For many other businesses, though, that additional benefit doesn't exist.
Very few of our clients have a "money is no object" attitude when it comes to budgeting for a web project. In fact, for many of them, our costs are a bit of a stretch. But they believe in the value of what we offer and trust us to lead them to the best outcomes. It would be wrong for me to push responsive design on all of them, indiscriminate of what they know about their audience, their actual visitor data, and their actual budget. If their money could be better spent in some other way, then it should be.
Superbly practical and down-to-earth article about responsive design.
Too many creative leads (and writers) jump onto the idea of responsive design like it's the next wonderfully shiny new toy that will display their leetness, without regard for whether or not it's actually suited to what they're producing. It's refreshing to see something so logical and well-thought out about the subject.
how Kindles replicate physical books is very subtle. Kindles do not rely on material aesthetics in quite the same way many skeuomorphs do. The design is underpinned by typographic and layout conventions (e.g., position of page numbers, chapter name and so on) allowing the aesthetics of the UI page to recede for the reader to become immersed in the author’s word. This is a quality any good book designer will tell you the design of a book should facilitate: uninhabited reading.
Unfortunately, the iPad book app doesn’t achieve this level of sophistication. It’s much more theatrical (as someone probably felt the need to take advantage of that fantastic color screen). The app employs elements like an overly-rendered paper texture and a faux page turn animation, which make it difficult to become quite as immersed in the prose of an author as the Kindle’s eInk design allows.
In many ways, the iPad book app was designed to look like a book, whereas the Kindle was designed to feel like a book.
Very good points that relate to more than just Kindle vs iPad design. Too many 'brilliant' and 'cutting-edge' designs sacrifice users' goals and purposes at the altar of looking good over being good for those using them.
Wouldn't it be nice to create prettier, more detailed versions of wireframes that can include all sorts of fancy icons, buttons and placeholders? With the Layout Lab's Web + Mobile UI PSD Bundle, you can do exactly that. Even better, you can work right in Photoshop.
And in answer? No, no I would not like prettier, more detailed wireframes with fancy icons and whatever else prettified is in there.
Where I'm concerned, as long as information is conveyed clearly, the uglier and more unpolished-looking the better when it comes to wireframes. ._.
Oh my eyes. Best (or is that worst) part is, the use of Helvetica Neue "Lighter" (not even the actual Helvetica Neue Light) was obviously intentional. Whoever designed this thought it was a good idea to make it look like this.
And they couldn't even get the implementation of their terrible idea right by using @font-face. Helvetica Neue doesn't come with the OS you know... If you really want it to look like that, so much so that you make it integral to your design and sit it on top of your font stack, then license the font.
Considering the client, one would think there's enough money for that.
P.S. If you don't have Helvetica Neue Light installed on your computer, thank your lucky stars, you'll actually be able to read the page.
Business Class: Freemium for News?
I had a perspective-changing talk on the subject of pay walls with the chief executive of a big publishing company (no, I can’t tell you who). He asked me what I think about pay walls. I told him what I always say: The main currency of news sites is attention not dollars, and that I believe that it is the publisher’s job to turn that attention into money, to keep the attention machine running. He nodded and made the following, astonishing statement:
“I can’t see pay walls working out either. But we need to do something before we lose all of our current subscribers. Sure. It’s a tough business environment, but… But the flight industry is a tough environment too, and they found ways. So tell me: Why do people fly Business Class? In the end, an airplane brings me to the same place regardless of whether I fly Economy or Business Class, and the massive price-increase I pay doesn’t compare the difference in value.”
He asked whether I knew of a way to apply this logic to online news. What would a Business Class news site look like?
“People pay for Business Class because they don’t want to be tortured in Economy. They get faster lanes at the security check. They get an extra glass of champagne. The stewards are more attentive. They get off the plane more quickly. They get the feeling of a higher social status.”
And he added that he wished that there was a way to lead each reader through to Economy again, to again show what they avoided by being in Business Class.
Interesting take on paid subscriptions for news.
I must confess, I'm one of those people who will not get a subscription even for news content I tend to like. NYT is the one that comes to mind. I find I like most of their articles, but ever since they put in the article cap (but still allowed users who were *linked* to their content to see said content), I simply Google every article I'm interested in, and find the 'back door' to see the content.
If they had a real distinction between economy and 'premium' though, I might just stop using Google as a back door.
Oh, and of course, they would have to properly convince me of the premium experience. Right now, for NYT, it just isn't coming through.
Wow! You folks at Technology Review have been reactionary and are STILL! being reactionary!
And you're leading business' and individuals who are trying to figure out what to do in the mobile arena with the impression that the technology is no god, when in fact it's your own lack of planning, design, project management and lack of technical expertise that caused every single one of your failures.
You heard the siren song of apps for iPad and Android and so you immediately decided that this is where your business needs to go. You did not do any research apparently into what it takes to design an app, let alone build it. You did not invest any time in learning what the limitations and strengths were in an app and more importantly for your bottom dollar...do didn't take the time to hire someone who could TELL! you what those values were and who could then advise you and/or lead the technology side of the project to build a quality app that takes advantage of all that the platforms have to offer. You didn't even look around to see that there are many technologies that will allow you to build mobile apps, and some extremley good technologies designed specifically for building apps for the publishing industry.
Instead you likey had a meeting or two with your planning group and with no actual data to base it on, you all gleefully said
"WE WANT AN APP! WE NEED AN APP!"
and then you called in your IT team and said,
"BUILD US AN APP!" and then, ...
"Uh...Say..CAN you guys build us an app?"
And they said, "Uh..an app? Uh...
(whisper: hey bob! what's an app? Never mind...I'll just wing it)..
"Sure boss! We can do that!"
and they then spent the next month reading articles online about how to build an app, and maybe even creating a 'Hello World' app in Objective-C. They probably even talked you into buying them some new Mac's to play around with...after awhile, they came to you and said,
"Hey boss, guess what? We don't know how to build an app. But Joe in the mail room has a cousin who rides the train with an IT guy who says he knows a consulting company who can build us an app."
And you said, "Hire them! WE NEED AN APP!"
and so the consulting firm was hired...but no one bothered to check to see if they had any experience prgramming in Objective-C or any other mobile development platforms for building an app...most definitely no experience to build an app like you wanted!...even though if you were being honest, you probably didn't really know what it was you wanted anyway at that point.
And they were turned loose with very little direction and very little oversight and every month this consulting firm sent you an invoice along with a "progress report" that probably consisted of some mocked up screen shots and a lot of jargon. And you were getting REALLY! excited and thought,
"OH MY GOD! WE ARE GOING TO HAVE AN APP WITH OUR NAME ON IT RUNNING ON AN iPAD!!!! OH MY GOD!!!! (uh-oh! I think I just wet my pants!)"
And eventually, the consulting firm learned, on your dime by the way, how to code an app in Objective-C and they delivered unto you an app with your name on it.
And you were ecstatic!
And then your team tried to port the content from next month's issue onto the app...and suddenly nothing fits. Columns don't line up, gutters are missing, images are pixelated and it looks like crap. And then someone accidentally rotates the tablet and suddenly the app REALLY! looks lke crap!
So now you work with the consulting company, who still hasn't admitted (and probably never will) that they cobbled together your app from 30 other sample programs on Apple's Develoepr website and they really have no clue of how to solve your problems. But you and they work together and you create a kludge that works on iPad. Then another kludge for Android tablets. Then a HUGE Turd of a Kludge for android smart phones and their small screens.
And hey, you have an app!
But after all this work and effort and money, you still have forgotten that no one has ever bothered to "DESIGN"! this app for useability!
You are amazed that you cannot click hyperlinks to exit otuside the app and you think that you've just tossed all your money and effort down the drain.
Then you read ANOTHER article about how company XYZ is now using HTML5 to build apps designed for any platform and you shout, "THIS IS IT! WE NEED AN HTML5 APP!" and you're starting all this all over again....
But you're just reacting again. You didn't do any research or talk to any developers with actual iOS or Android developer experience to find out WHY! your orginal app didn't work right. You just assumed that since some things did not work as expected that it must not be possible. Guess what? You are wrong in those assumptions.
Every single "wrong" thing you wrote about is absolutelly technologically possible and none of them are hard to do. Your IT-developers simply lacked real world experience and were afraid to lose the gig so they never told you that. They did not know how to properly code the app to do simple things like allowing hyperlinks to take the user out of and back into the app, as needed. Although in their defense, it sounds like there was no one at your company providing a design plan for them to work from or providing project leadership to make sure that all those features you wanted were in the app and working as you wanted prior to releasing it to the public.
And I could go on and on but your whole article just tires me and I grow weary of trying to shine a light on your FAIL . I will add just one more thing...You should not be rushing to dump your $125K investment in your app just so you can build it again with HTML5.
HTML5 has not even been finalized yet. It's currently in beta mode (go ahead and google beta...based on your experience with the app development I'm guessing you don't understand that term). HTML 5 is also not supported by the majority of browsers yet and the latest projections I saw said it would be 3rd or 4th quarter 2013 before that happens. No one is building production level code projects in HTML 5 yet. Everyone agrees that HTML5 is the future, for sure, but it's no even lose to being ready for it yet.
Just do your research and planning first this time, and if after everything you fail with HTML 5 too, don't bother writing an article about how terrible HTML 5 is becuase your app sucked like you did with developing native mobile apps.
I wouldn't have even bothered commenting except I didn't want some reader who is looking for information about mobile app development reading your piece as gospel. They deserve to know that your experience is not based on any technical limitations to native mobile apps, but rather to terrible project management/planning/design/programming.
This is wonderful. Lol. This is what I tried to prevent when I designed and wrote this page (the site's been redone, so this is a link to a screenie).
but... oh well. XD