Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Back in the days of Unix, you couldn't even close a software without reading the man page first. Then came Mac and Windows with consistent menu layout and keyboard shortcuts, but you still saw paper user manuals shipped in the shrinkwrap box, which described each and every single operation possible in the app. After the Internet, help files became html documents.
Nowadays with Web 2.0 applications, you hardly see the Help. Even if it's there, they simply describe some specific tasks. In other words, the apps are relying more on the common sense or don't-make-me-think factor of the user base.
Years ago Microsoft came up with a concept called Inductive User Interface, which basically tells programmers to put in instructions on the apps itself, but I am not sure how popular that idea is.
Are help files, user manuals, and context sensitive online help with F1 key dead? Have I failed if user could not find out what to do from the UI? If not, what degree of help should I provide? (both for desktop and web app)
EDIT: How does documentation/help file mesh with agile development methods? For example, should the developers think twice before UI changes that may obsolete a bunch of screenshots?
Three notes on help:
F1 / stand-alone context-sensitive help was always doomed. It was hidden by default, and so the people who most needed it were least likely to read it. There was hope at one time that we would be able to train users to always hit F1 when they ran into trouble, but too many applications without useful context-sensitive help... combined with too many bizarre help interfaces... pretty much killed this.
Manuals are as important now as they ever were. Not so many printed manuals anymore, but online manuals are better than ever. The proliferation of wiki-as-a-manual systems has helped here, reducing the up-front cost of creating good online documentation. Of course, plenty of people just don't read...
The beauty of using web pages as an application interface is that you can combine useful context-sensitive help with the UI, removing the barrier for novices and others who otherwise couldn't be bothered to look for relevant information when they get stuck.
Of course, there are still plenty of apps, even online apps, designed with obtuse interfaces and a tiny little help icon in a corner somewhere, presumably hoping that the latter mitigates the former. Pity them.
No way. You look at the amount of documentation and training and marketing expenditure even MS puts up.. you'll get your answer.
Try using someone else's product, and you will learn the true value of documentation - I'm learning Godiagrams right now.. :)
So I can say without a doubt.. NO and it never will.. no matter how intuitive user interfaces get.. beyond a certain size, you will need help and training. But by understanding the user and what he needs to get done, you could design it such that the time he/she needs to learn the system to do his/her routine tasks is minimal.
Have I failed if user could not find out what to do from the UI?
If not, what degree of help should I provide? (both for desktop and web app)
They should be able to use your your app to do basic things from the UI. eg say for an image editor, they should be able to create a new image, and draw some lines then save it just by looking at the UI.
This is best done by following common layouts (like having new, open and save under file in the menubar, and using the standard open and save dialogs).
The same goes for webapps, people exspect to be able to do the basic stuff without having to read the docs, but for more advanced features people will still read the docs. (eg most pople will read the docs for say BB code, or markdown at least sometimes, but they expect to be able to post without having to know them)
Are help files, user manuals, and context sensitive online help with F1 key dead?
They still have their place. People will use them to learn about how to best use various features, for example markdown or bbcode, or how to use filters to get certain effects in an image editor.
I've been incorporating context-sensitive screencasts into my applications. I've found this helps non-technical users grasp the application quickly, without asking for live help.
The Idiot/Dummy books must be doing quite well. Imagine if the standard application help was as good as those books. The standard F1 help for a lot of apps is just awful.
Is help dead? No, but some of it should be taken out and shot.
Related
I recently had a discussion about the use of contextual help in applications with my colleagues and the argument was if there is a need for it these days or if it's something that many companies do but does not actually have any significant benefit to the end user. Would we be better off having just pdf files or chm files without any context sensitive help in our applications? I was just curious as to what other developers think about it, primarily because context sensitive help is a bit of pain to set up and especially if you depend on a small number of developers.
As I see it, most applications seem to provide one topic per screen.
If you see a phrase that is not clear in a dialog, you want to be simply able to press F1, and be in the topic.
But of course, the commenters are also right. If it considered a chore, and that topic consists out of a screenshot of the form and the exact same texts mechanically repeated, it won't be any help.
But then of course, the manual won't be any more help when created with such attitude either.
Many applications are let down by the quality of the 'writing' in their user interfaces: typically, poor spelling, grammar, inconsistent tone, and worse yet, "humour" are the usual offenders.
Are there good resources that can help developers to write UI messages that give a professional and positive impression to your customers, even when your code's going to hell in a handcart?
Thanks, all — Some great resources here, so I will CW this question. I'm accepting Adam Sill's answer because it's the one that (as a developer of desktop apps) I found most pertinent.
Since XP, I've been a fan of the Windows UX Guidelines sections that cover how to properly structure text (how to ask questions, how to make assertions in dialogs, etc).
http://msdn.microsoft.com/en-us/library/aa974176.aspx
http://msdn.microsoft.com/en-us/library/aa974175.aspx
Read The Elements of Style. Then re-read it.
Also, anytime you are working with a program or website make a conscious effort to notice how they choose to do their writing. Imitate those you like.
The resources found at Writing for the Web might be useful to you.
The best tool for this is called "primary education". Many developers seem to have missed this, and I don't know how to fix that problem.
Also, this may be a British thing, but I think you mean "humor" and "going to Hell in a handbasket". :)
This book has a lot of good advice:
GUI Bloopers 2.0
Short version:
Be consistent throughout your application or app suite. Don't call the same feature two different names, even if they're in different dialogs, etc. Develop a product lexicon that everyone references.
Use the same terms that people who use your software use (i.e. users don't refer to themselves as users).
Don't call two different things by the same name.
Put all of the messages displayed to the user in a central place (i.e. a resources file of some kind). This makes it easy to review all of the messages for spelling, tone, consistency, and whatever else you want to check.
Usability test your software to see if the messages make sense and people can use your software easily. If they can't, change the resources file and test it again.
I would suggest showing your UI to as many people as you can--preferably people who read a lot (Just because reading does wonders for your grammar and vocabulary).
Getting something out that people can examine, however, is awesome--even if it's just a demo of the GUI.
If you work at a company, get to know your QA and Tech Support people. They are usually really wonderful once they understand what you are trying to do--they will review your UI, give you input on text and usability as well as possibly new requirements nobody in engineering would come up with.
If you work on your own, try to find a potential customer or two to review your UI. Ask them to pay attention to the text...
The more eyes, the better. You might even ask your parents, wife or other family. What can it hurt?
Get your application's texts proofread by someone who does just that for a living. Then the UI walked through by someone who does usability for a living. Neither of these two people should have been involved in the development.
It's the only way to make sure.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I have been looking for a collaborative tool for developing functional specifications. I am looking for the ability to:
Have multiple users contribute to the specification.
Provide some form of traceability, which could be done manually if needed.
Provide users with the ability to add comments and notes.
Upload and display Visio documents
Upload and display mockup screens using Balsamiq Mockup.
My initial impression is that using a wiki could be a good tool for this task. Does anyone have experience with using a wiki for creating functional specifications? What would be the pros and cons to using a tool like this as opposed to a requirements management tool?
Your input is greatly appreciated!
It's possible to do what you describe, to develop requirements in a collaborative way, in spite of using a wiki. Nothing about the wiki paradigm assists in this process.
I managed a wiki on the Zend Framework project to track proposals for components. They're still using it. Proposals are different from functional specifications, but the usage is similar enough to your question that I think this is relevant.
A wiki doesn't take care of itself. Unless you have someone responsible for managing it and making sure there is some structure and consistency, it quickly becomes a mess. The real-world analogy would be to hand each of your team a blank sheet of paper and tell them to write up their part of the requirements. Problems with this are:
Every contributor has to make up their own document structure, and write about different things in a different order. So it's impossible to compare one page to another.
There's no "index page" to organize all the disparate contributions. No one wants a page to "fall through the cracks," but in a wiki that's the default destiny of any page as soon as it's written.
There's no feedback loop to make sure the writing actually gets done.
The way to make it work is to apply some process to the project, and use the wiki in accordance with that process.
Give people the ability to create a new page in the wiki, but only through an interface that automatically links the new page into the right index.
Define a lifecycle for documents, so they are sure to be drafted, reviewed, and approved at the appropriate stages.
Provide a template for a new page. Provide the section headings that you need in each of these pages, and make part of the review process a confirmation that head section has been filled out adequately.
"What would be the pros and cons to using a tool like this as opposed to a requirements management tool?"
While it seems like a great idea, what you run into are people who can't and won't write.
People who can't write -- well -- can't write. They can't communicate with an email or a wiki or any medium outside voice.
Some people are "disorganized". Actually, writing is too linear and they don't think linearly.
Some people don't get the "write to your audience" and write stuff that's incomprehensible.
Sometimes you can't even figure out what they're talking about, much less what they're writing about. They talk in jargon or code. They don't know much but insist on being heard.
Some people won't write.
Some people refuse to make commitments. Even in a wiki where it can be retracted. They feel they must pre-discuss everything.
Some people are in the habit of doing everything by giving direction to someone else. They either don't write for themselves, or, they make people stand around in their office and listen to them talk and type.
Some people are generally toxic on any kind of project. They spring new requirements at the last minute. Their first response is "that will never work". They don't brainstorm well. When they say it work work, and you beg them for an improvement, they don't have one. They just know it won't work.
My experience is that only programmers can use a Wiki successfully. And only senior-level programmers.
N00bz don't have enough experience to sort out requirements from design from rumors and management fluff.
N00bz don't always have the language skills to write clearly. They may eventually, but one look at their Javadoc comments indicates that they're struggling with the "clarity" part of writing.
It's very appealing. I'm hoping for people to get better at using wiki's because I think it could have a lot of advantages over more traditional approaches where one person interviews everyone and writes things down. But it requires a level of confidence and skill in communication that few people seem to have.
Consider researching Fog Bugz. They tout themselves as the best of the
best for project management. Considering Joel's history I'd give them the
benefit of the doubt. They use a wiki in the way you've just described.
I would suggest signing up for the free trial, if you're serious.
Depending on the size of your project, buying it might be a very good
option.
At very least you could look at how they've structured it, or read the
forums for ideas on how to build your own stripped down version
Specialist tools help keep things on track and introduce a fixed work-flow. This is kind of the point, keeping things focused and functional. Using generic tools like a Wiki might be great for a bunch of programmers but introducing one for 'mixed-mode' work might be bad:
Things can creep and get off-track quickly
Communication can be lost in the medium
Look at things like Basecamp. They can be thought of as an applied wiki, or collaborative tool. A generic tool for specific purpose needs refining. I don't know if MediaWiki or others have enough customization to keep things clean and focused.
Maybe gather the requirements for your requirements management tool (recursive I know) and what aspects (communication aspects) you can take from the wiki culture and an open-communication mindset. If neither requirements management tools or wikis fit the bill, look at building one. Might be the next big thing. It feels like saying Could I use a wiki instead of Bugzilla?
A fixed work-flow webapp for requirements management with an open-communication emphasis that allows people from many roles to see and understand might be good!
We have used TWiki and now FosWiki in that context. There are many things one gets for free (version control, access control, Web-base access, searches, remote management, security patches, ...). In a few minutes, one can define:
a table defining requirements attributes,
which creates interactive forms with field selection and validation (where you can also document discussions and rationales, embed images, attach documents, link to other requirements...),
and then queries on these "requirements" and show them as tables that can be sorted, filtered, printed, reported against, etc. (e.g., http://jucmnav.softwareengineering.ca/ucm/bin/view/ProjetSEG/JUCMNavRequirementsVer2).
Obviously, one can easily use hyperlinks and Wiki links along the way. FosWiki also has features that can be used to enforce specific workflows, if needed. It is also easy to support forms for use cases and other paradigms (we have done this in the past, and that works generally well).
Wikis such as FosWiki are extensible and one could develop further modules for addressing weaknesses related to traceability management and impact analysis, table-based modifications of requirements, overall packaging, etc.
As a middle ground between a free-form wiki and a requirements management tool, consider using a structured wiki like Foswiki. I haven't done any formal requirements management (with a wiki or otherwise), but I have used TWiki (the predecessor to Foswiki) for other tasks, and it permits you to define a workflow, form fields, and so on as you need them, while keeping the flexibility of a wiki when you don't need a formal structure.
I agree with all (most) of the people above - use of a wiki may sound ok, but wiki's are meant to be present information and be updated as needed, not to be used as an interactive project management tool. I would strongly suggest SmartSheet (I'm a strong advocate of the product) - it provides a spreadsheet like interface where you can store multiple files per row/task, send out automated updates to users and maintain specification revisions...
The other approach could be the use of Google email, docs and calendar - a free friendly way of team interaction....I would shy away from issue/bug tracking tools for project management - they tend to have differ on focus: PM tools on the entire project/resource/timeline and Issue tracking tools for specific entered issues....
This may be a bit old now, but I am currently using Atlassian's "Confluence" and it's been great. I currently work as a UX engineer playing the role of "Product Owner" within an Agile process. I can document requirements for discrete interfaces, allow for multiple users' feedback and comments, and intertwine each interface with other interfaces within a larger context (e.g. user story). Everything is very dynamic and template driven. It's suiting my current needs very well.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 8 years ago.
Improve this question
I will start developing my next desktop application in about a month. In the past I have delivered functional software that hasn't wowed anyone, including myself, in the usability or aesthetics department.
Does anybody know of any resources or guides or even books that could showcase examples of good design in desktop software?
There seems to be a lot of resources for web apps, but such resources for desktop applications are rather slim.
I enjoyed these dot net rocks tv videos by Mark Miller on The Science of a Great User Experience really got me thinking about good ui:
http://www.dnrtv.com/default.aspx?showNum=112
http://www.dnrtv.com/default.aspx?showNum=123
Where you can really make a difference with GUI design is if you are addressing a difficult to understand concept in a GUI.
When you are doing that, creativity is critical. When dealing with complex hardware configurations (something I had to do a lot, but probably doesn't apply to you), I've had good luck going to tech manuals and tech support people and trying to completely understand the problem. Then I took the methods they used to show me (diagrams from the manuals, whiteboard drawings, etc) and tried to code them into a GUI.
Had a couple massive successes with this.
Iteration is also critical. Prototype something quickly then beg everyone you see to try it. Ask them to solve a problem, then watch where they go first and watch what they have problems with.
Address every problem and stumbling block.
Don't be afraid to throw it all away and start over, it was only prototype code.
Separate your GUI from your implementation so that you can swap out the GUI if you find a better approach.
If you want to concentrate on just one feature, have a look at ITunes' search box which filters as you type. Other software may have had this before, but this was I think the first place I encountered it.
The difference between this and classic search was an eye opener for me in terms of readability.
Auto-complete which you see in so many places is another one. I'd recommend IntelliJ IDEA for the way it took auto-completion which emacs, Visual studio etc had for ages and added autocompletion for variable names and method names in a manner which almost seemed psychic the first time you encountered it.
You can look at Thirteen23 Experiences
To make things usable, you need to make sure that you follow existing conventions for your target platform and application type.
For example, if you're developing a Windows App you'd better make sure that control-c copies, control-v pastes, control-s saves, etc. The File menu better be the leftmost item in the menu bar, and the Help menu better by the rightmost item.
If you don't follow existing conventions, users are going to get annoyed with your application very quickly.
Google for HIG. Human Interface Guidelines typically include lots of research into best-practice in user interfaces, and explain in great detail how to design each aspect of a program. Also, have a google for "user-interface hall of shame" or something like that.
In this question I mentioned GUI bloopers. Part of great design is knowing what makes bad design and why. It is actually a great book, although I don't know how much of it is available on the website.
You can check case studys on websites of GUI companys. I fund few at www.puzzlehead.com
Check there and also other sites.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I think it would be interesting to get a programmers viewpoint on UI design.
What is your favorite User Interface that you have come across in a web application?
If possible, say a little bit about why you like it.
http://www.google.com is my favorite. Can be considered a "lack of UI" ;)
At the risk of sounding too much of a fan ... I think StackOverflow has a great UI. It is clean, without clutter (except the creeping ads!), the navigation is straight forward and yet manages to compress a fair amount of functionality.
Fairly simple features, like the coloured vote buttons to show what you have voted for, and the live preview really add to the interactive feel.
(And I don't mind the ads as long as they stay away from the flashing punch-the-monkey kind!)
Web application: Wordpress. It's so powerful, yet clean and easy to use.
Desktop application: Excel (or equivelent). Seriously, a spreadsheet is the most innovative and clever user interface ever devised. It's used for everything. I don't know what the question is, but the answer is Excel.
GMail interface is so smooth and fast that I question me why nobody had done that before.
I think Remember The Milk has a brilliantly clean and intuitive interface
Mint.com, if you trust someone else with your bank account information. It keeps track of all your transactions, lets you fill out a budget, notifies you of unusual spending trends or transactions, and lets you drill down through your spending trends to see exactly where all of your hard earned cash is going. Best of all, it's free.
(source: mint.com)
http://bbc.co.uk homepage
http://mail.google.com/
http://stackoverlow.com (that is I liked it before the introduction of ads :)
FreshBooks accounting has a very nice interface.
(Although I upvoted the answer in favor of StackOverflow)
I think stackoverflow has done a great job in many areas in terms of usability, including colour pallete, use of whitespace, anticipating user's need for information and providing or hiding appropriately, non-intrusive JS/AJAX.
Minus points for these increasingly obtrusive ads, though. :P
Gmail is also good. Honourable mention to github.com.
Update: I recently got introduced to FriendFeed. I think they have also done a fabulous job with their web UI, in terms of clean yet attractive design, plus appropriate and helpful use of Javascript and AJAX to provide for a smooth, positive user experience. Check it out.
The new Yahoo Mail UI blew me away when I first saw it. The keyboard shortcuts, drag 'n' drop, tabs, etc. really make it look and feel like a desktop app. Admittedly this quality of UI has become a lot more common on the web in the last few years, but for me at least, Yahoo Mail was the first web app in my experience to bring this kind of usability to the web.
http://fastladder.com has great UI for feedholic. I can't live without fldr's keyboard shortcuts (and some greasemonkey to change them to fit for me.)
http://www.instapaper.com is also simple and great. This is temporary storage for web resource marked as read later, and don't need password for make account because of that purpose.
For the CLI lovers out there...
http://cb.vu/
cat about.txt
Not really useful but it's quite interesting.