I work as a UX designer for a company who makes a creative application for the live video events space.
I want to do some work on information architecture for our product. The software is complex (think photoshop) in its layout.
Is a site map a good approach to mapping objects with in the software with windows and menus? Is there another option for building an overview of information contained.
Cheers Jim
A Sitemap makes more sense to me when you are actually creating a website. What you describe is a software with probably multiple features and a very clear goal.
I don't want to forget my favorite tool: pen a paper.
But also, I would do a Content Inventory and use it to create an Affinity Diagram so you can Categorize which features you will display where and how the information will be shown. Don't be afraid to explore about Databases and how relationships between data might be. You will have to iterate on this several times and do some Data Modeling at this point.
Also, if it is that complex, I would create Tasks Flows and User Flows to understand how the user will complete tasks from top to bottom better.
At the end, you will have to model Navigation and processes with a certain Hierarchy. Usually, I rely on B&W wireframes better than anything as they help me represent better the visual impact step by step.
Hope this helps and lots of luck!
I don't think a "site" map in the traditional sense will really help you. However, some elements like hierarchy & categorization certainly sound useful.
I think I would use traditional artifacts like a card sort if you're talking to users. Otherwise, you run the risk of confusing the issue (applications don't utilize links in a traditional site map structure).
For you, and/or internal team members, I wonder if mind mapping tools would help?
You could also use some visual design program to lay out all the options/sub-options in physical space. Imagine an interface with all options expanded. This would give you a better way to audit all features and make sure you're accounting for everything.
Finally, journey maps or storyboards that utilize interface options in the steps, should be created for the highest priority tasks/workflows. This helps you know how to deal with interface changes (eg picking settings for a process).
Related
I'm searching for sources and further information on a particular concept in user experience design. It's not a particularly complicated concept, just that when designing user interfaces, you should both make it intuitive and simple for new users, but also provide way for users to become more efficient as they become more familiar with the application.
An example could be including a prominent button for a common action for new users, but also providing a keyboard shortcut / mnemonic for expert users. However, that's just an example, another example could be providing full functionality through a GUI, but allow expert users to script the same actions. The point is it's more difficult to learn, but it makes them more efficient.
I'm pretty sure there's a name for that which I can't recall, and I'm having trouble searching for sources and references on it.
Name of the concept of designing an interface to allow expert users to become more efficient?
Accelerators?
Flexibility and efficiency of use:
Accelerators -- unseen by the novice
user -- may often speed up the
interaction for the expert user such
that the system can cater to both
inexperienced and experienced users.
Allow users to tailor frequent
actions.
(source: Ten Usability Heuristics by Jakob Nielsen)
Well, reading only your question "Name of the concept of designing an interface to allow expert users to become more efficient?" I'm inclined to point you toward The Humane Interface: New Directions for Designing Interactive Systems by Jef Raskin, in which there is the concept of habituation:
2-3-1 Formation of Habits
When you perform a task repeatedly, it
tends to become easier to do.
Juggling, table tennis, and playing
piano are everyday examples in my
life; they all seemed impossible when
I first attempted them. Walking is a
more widely practiced example. With
repetition, or practice, your
competence becomes habitual, and you
can do the task without having to
think about it. ...
...
... The ideal humane interface would
reduce the interface component of a
user's work to benign habituation.
Many of the problems that make
products difficult and unpleasant to
use are caused by human-machine design
that fails to take into account the
helpful and injurious properties of
habit formation. One notable example
is the tendency to provide many ways
of accomplishing the same task. Having
multiple options can shift your locus
of attention from the task to the
choice of method...
But is contrary to what you describe in your question, as evidenced by the last 2 sentences. In fact in that book there is also a sub-chapter dedicated to dispel the myth of beginner-expert dichotomy:
3-6 Myth of the Beginner-Expert Dichotomy
... This dichotomy is invalid. As a user
of a complex system, you are neither
a beginner nor an expert, and you cannot
be placed on a single continuum between
these two poles. You independently know
or do not know each feature or each related
set of features that work similarly to one
another. You may know how to use many
commands and features of a software package;
you may even work with the package professionally,
and people may seek your advice on using it.
Yet you may not know how to use or even know
about the existence of certain other commands
or even whole categories of commands in that
same package. ...
So, perhaps is not such a good term/concept that you are looking for.
Update: were you looking for the term Adaptive User Interfaces, perhaps? Well, I think that, as usually understood and implemented, it is not such a great idea (for example, disappearing menu items in Microsoft products). But my impression is that researchers use the term for something quite different.
Update: but Adaptive User Interfaces does not cover scripting.
The answer is in your question: Efficiency. It's a fundamental component of usability that Jakob Nielsen long ago defined as "Once users have learned the design, how quickly can they perform tasks." A UI with expert-supporting elements like accelerators, context menus, and double-click-for-defaults is an efficient UI.
It is also correct to simply say that making things fast for experienced users is part of usability -just as usability also includes making it easy for users to accomplish basic tasks on the first encounter, and making it satisfying, and tolerating errors.
I'm a recent graduate who is looking to get a job doing user experience. Next week, I have a technical interview in which I will be given a website and will have to talk about its usability issues as well as come up with ways of improving the user experience. I feel I have the natural skills to do this and have been doing a fair amount of reading into the subject, but I would like some further advice on how to effectively critique different kinds of websites.
Does anybody have any suggestions of common faults I should look out for, or advice on ways of structuring my evaluation in order that it is relatively air-tight and I do not miss anything obvious?
As I've said before, I'm already doing a lot of reading and I realize that practice makes perfect. However, I'm hopeful that those that have long-term experience with this can help me by imparting their wisdom on gotchas, common issues, and what to look out for in a good/bad website.
Thanks in advance!
How easy navigation is
Whether a user can easily find what he needs without resorting to "search" function. Edge case: whether a user can find the search input field without using the browser's search function (Ctrl+F)?
Whether a site is browsable with images turned off
How many clicks it takes to accomplish an operation. Is that many really necessary?
Are the most important / frequently used features right there in front of the user?
Whether you communicate with the user in geek language
Whether you overwhelm the user with long literary texts where one or two words will suffice
Whether you use standard ideas in your UI. Do buttons, links and menus look like buttons, links and menus? Do they also work that way?
If UI is made up of a limited set of controls with consistent look and behavior? Or each page is unique and has to be learned from scratch?
Whether UI is accomplished with mostly 2-3 colors or uses different colors everywhere to look cool
Also check out the following questions:
Worst UI You’ve Ever Used
What are common UI misconceptions and annoyances?
Why is good UI design so hard for some Developers?
What is the best UI you’ve ever used?
As the other answers have talked a bit about usability I'll mention some things about accessibility (although good accessibility and usability go hand-in-hand).
First of all you need to get the usability correct - a site with poor usability will straight away mean that it will almost certainly also have poor accessibility. Make sure it makes sense, is easy to navigate and is structured meaningfully - for good accessibility that needs to be reflected in the markup as well as visually (so use headings correctly, use things like (strong) instead of (b)old, etc). Automated tools can provide some limited help with this.
Secondly make sure you use the various pieces of markup that are available which will enhance usability (e.g. alt tags on images). Automated tools are excellent for this.
Next if you're going to use technologies like javascript try to use progressive enhancement so that users without those technologies available still have a workable experience. Automated tools won't help much with this.
Finally don't get lured into thinking that an accessible website is a dull boring featureless one - for every user with visual difficulties there will be many more who have cognitive difficulties such as dyslexia. The aim is to make it engaging for everyone, not cripple it for a minority of users (who will likely also be penalised if you start slashing content - for example youtube is one of the most popular sites for blind users).
My thinking process :
See what's different. I mean ask yourself, "is this button here also done that way on youtube/google/basecamp/whatever has been proven good enought".
If it's not the case, I ask myself "does it make sense to do it differently?". If it doesn't make sense, then it shouldn't be that way to avoid confusing the user.
If it makes sense, I ask myself "If it's not obvious, what's the learning curve for the user?", always keeping in mind that "the user" is not IT.
Then I'd see if I can improve it. If I can't, maybe you can't improve it, so even if the control is not perfect it's good enough.
Finally ask yourself "what does the website wants the user to do?". Is it buying something? Subscribing? It's all about figuring out what's the objective. Then see if the website is oriented toward something aiming to complete this objective.
As well as practical ideas about usability problems, you might want to think what kind of process you'd use to do this work (and how it would fit into the company's development process). Would you start out with research? How would you present your analysis and feedback?
Core Data is pretty amazing, and I've really enjoyed using the visual layout Xcode provides for it to organize things and get a quick sample of what data I've placed where. At times I've started to wonder if I'm making the best use of it, however, as after a while there tends to be such a mass of arrows that it becomes difficult to tell what's going where.
I try to keep this to a minimum by
grouping like objects together,
abstract objects/parents in trees with their children,
etc.
but the clutter seems inevitable.
What are some ways you employ to keep it optimally organized and readable?
This is difficult to answer in a general sense. I think it's important and you're right to give this some good consideration. I tend to obsess over the visual arrangement of things myself as I find it has a profound affect on my perception and ongoing understanding of my own schema. Xcode's data modeler is essentially a schema design and design documentation tool.
I strive to compartmentalize my own designs as much as possible. For example, if you consider an iTunes-like case, you might have a controller managing the library source list selection (a playlist, for a simple example), and another managing the members of the selected playlist. In the schema, there may be several "library-related" entities and several "playlist-related" entities, and there are definitely several "song-related" entities (album, artist, and song/track). I'd group the song-related stuff tightly together in a way that nicely arranges the relationship lines, but that keeps these entities visually separated by space from playlist- and library-related items.
In other words, if you keep related items together in clearly-defined logical clusters, separated by nice whitespace, organized in the same way you'd organize your controllers, the concepts are kept fairly clear.
The other problem is Xcode's automatic placement of the relationship lines. Unfortunately, there's little we can do about making those neat. I've been known to spend (actual time redacted out of embarrassment) worrying over balancing clearly-depicted relationships with clearly-depicted clusters of interrelated entities.
Good luck and happy OCD! :-)
here's better suggestion.
http://www.sebastianrehnby.com/blog/2013/01/15/structuring-an-ios-project/
Additionally, Services module, Helper module(your app utility classes)
services - (calling external services like your back-end server, DBOject services)
Also, this one
http://www.slideshare.net/MassimoOliviero/architecting-ios-project
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
In my experience, UI programming is very time consuming, expensive (designers, graphics, etc) and error prone - and by definition UI bugs or glitches are very visible embarasing.
What do you do to mitigate this problem?
Do you know of a solution that can automatically convert an API to a user interface (preferably a Web user interface?).
Probably something like a JMX console
with good defaults
can be tweaked with css
where fields can be configured to be radio button or drop down list, text field or text area, etc
localizable
etc
Developing UI is time consuming and error-prone because it involves design. Not just visual or sound design, but more importantly interaction design. A good API is always interaction model neutral, meaning it puts minimal constraints on actual workflow, localisation and info representation. The main driver behind this is encapsulation and code re-use.
As a result it is impossible to extract enough information from API alone to construct a good user interface tailored to a specific case of API use.
However there are UI generators that normally produce CRUD screens based on a given API. Needless to say that such generated UI's are not very well-suited for frequent users with demands for higher UI efficiency, nor are they particularly easy to learn in case of a larger system since they don't really communicate system image or interaction sequence well.
It takes a lot of effort to create a good UI because it needs to be designed according to specific user needs and not because of some mundane API-UI conversion task that can be fully automated.
To speed the process of building UI up and mitigate risks it is possible to suggest either involving UI professionals or learning more about the job yourself. Unfortunatelly, there is no shortcut or magic wand, so to speak that will produce a quality UI based entirely and only on an API without lots of additional info and analysis.
Please also see an excellent question: "Why is good UI design so hard for some developers?" that has some very insightful and valuable answers, specifically:
Shameless plug for my own answer.
Great answer by Karl Fast.
I don't believe UI programming is more time consuming than any other sort of programming, nor is it more error prone. However, bugs in the UI are often more obvious. Spotting an error in a compiler is often much more tricky.
One clear difference between UI programming is that you have a person at the other end, instead of another program, which is very often the case when you're writing compilers, protocol parsers, debuggers, and other code which talks to other programs and computers. This means that the entity you're communicating with is not well-specified and may behave very erratically.
EDIT: "unpredictable" is probably a more appropriate term. /Jesper
Your question of converting an API to a user interface just doesn't make sense to me. What are you talking about?
Looks like you are looking for the 'Naked Objects' Architectual pattern. There are various implementations available.
http://en.wikipedia.org/wiki/Naked_objects
I'm not providing a solution, but I'll attempt to answer the why.
So I don't speak for everyone, but for me at least, I believe one reason is because programmers tend to concentrate on functionality more so than usability and they tend not to be too artistic. I think they just tend to have a different type of creativity. I find that it takes me a long to time to create the right graphics, compared to how long it takes me to write the code (Though, for the most part, I haven't done any projects with too many graphical requirements).
Automatically generating user interfaces may be possible to some extent, in that it can generate controls for the required input and output of data. But UI design is much more involved than simply putting the required controls onto a screen. In order to create a usable, user friendly UI, knowledge from disciplines such as graphics design, ergonomics, psychology, etc. has to be combined. There is a reason that human-computer interaction is becoming a discipline of its own: its not trivial to create a decent UI.
So I don't think there's a real solution to your problem. UI design is a complex task that simply takes time to do properly. The only area where it is relatively easy to win some time is with the tooling: if you have powerful tools to implement the design of the user interface, you don't have to hand-code every pixel of the UI yourself.
You are absolutely correct when you say that UI is time consuming, costly and error prone!
A great compromise I have found is as follows...
I realized that a lot of data (if not most) can be presented using a simple table (such as a JTable), rather than continuously try to create custom panels and fancy GUI's. It doesn't seem obvious at first, but it's quite decent, usable and visually appealing.
Why is it so fast? Because I was able to create a reusable framework which can accept a collection of concrete models and with little to no effort can render all these models within the table. So much code-reuse, its unbelievable.
By adding a toolbar above the window, my framework can add to, remove from or edit entries in the table. Using the full power of JTables, I can hide (by filtering) and sort as needed by extending various classes (but only if/when this is required).
I find myself reusing a heck of a lot of code every time I want to display and manage new models. I make extensive use of icons (per column, rows or cells, etc) to beautify the screens. I use large icons as a window header to make each screen 'appear' different and appealing and it always looks like new and different screens, but its always the same code behind them.
A lot of work and effort was required at first to do the framework, but now its paying off big time.
I can write the GUI for an entirely new application with as many as 30 to 50 different models, consisting of as many screens in a fraction of the time it would take me using the 'custom UI method'.
I would recommend you evaluate and explore this approach!
if you already know or could learn to use Ruby on Rails, ActiveScaffold is excellent for this.
One reason is that we don't have a well-developed pattern for UTDD - User Test Driven Development. Nor have I seen many good examples of mapping User Stories to Unit Tests. Why, for example, do so few tutorials discuss User Stories?
ASP.NET Dynamic Data is something that you should investigate. It meets most, if not all your requirements
It's hard because most users/customers are dumb and can't think straight! :)
It's time consuming because UI devs/designers are so obsessive-compulsive! :)
Say for instance I'm going to do some seat of my pants coding adding a feature to an enterprise app. What are some good examples/tenants/cardinal rules a person can follow for making a fairly complex setup/config screen not look like feet.
What I'm looking for is along the lines of "Don't put one thing in a group box". But I'd also like some help with symmetry if anyone knows what layouts are most likely to achieve a relative amount of good looks that would be helpful.
Here's a cardinal rule you asked for: line up the controls vertically /horizontally and equally space the various related elements. And use correct spelling on your labels!
We've all come across screens where there are misaligned controls (even a couple pixels is noticeable) or misspelling on labels. When this happens to me I can't help but subconsciously look for other mistakes, plus it decreases my confidence in the application I'm using!
This is actually a huge topic. I frequently go to the Microsoft UX Guide for reminders on how to do this.
Some basics:
Make your app read like a book: left
to right, top to bottom
Use goal-oriented language instead of
technology oriented language
Not a cardinal rule but a great resource:
Apple UI Guidelines (good info for any OS)
EDIT: Re: achieving symmetry - things don't have to be perfectly symmetrical, but you want a feel of balance. Take a step back and get a sense of whether the page or form feels like it's leaning/falling to the left or right.
E.g., with stackoverflow, the main content is to the left, but it's nicely balanced by the extra stuff on the right.
I find that paper is my friend. I like to write out a list of objectives the form has to accomplish, and then sketch the form by hand, labeling the parts. Drawing it out lets me get away from making sure it looks perfect and that everything is aligned just right, and lets me focus on making sure that all the components I need are placed, hopefully somewhere logically. It also forces me to lay out the UI twice, so by the time I open my UI designer, I've already designed the form once and you hopefully know what I am doing
Some basic rules for you.
Try to make effective use of whitespace. Don't cram everything together in an effort to get as much stuff on screen as possible. This will make grouped controls more clear and text more legible.
Basic typography. Limit your use of fonts to 1 or 2. Don't use bold too much or it loses its emphasis.
The same goes for colours. Don't use too many, the fewer the better most of the time.
Don't just use icons to save space. Tiny icons with no explanation are useless.
Copy. Not wholesale of course, but if you are not well-versed in UI design yourself, it makes sense to take elements of interfaces you know work and apply them in your own designs.
Be clear about the purpose of the interface. How does it fit within the broader application for example? And what are the specific objectives you are trying to satisfy with it?
Get people to test it for you, early and often. I don't know what setup you are working with, or what kind of organisation you are in, but getting some kind of human feedback on your work will always be helpful, even if you lack the time and expertise to conduct proper usability evaluations.
Since you use the term, "seat of your pants," I'm assuming that you don't want to spend too much time on the UI. If you are willing to devote some time to the UI, you may want to look into custom control or UI development that will suit your situation. Like Firefox's Options UI or the .NET project properties in Visual Studio 2008.
If you are looking for something using standard controls, it is probably best to separate out different sections of related items into tabs or some other type of stacking control (i.e. Ribbon control). A good example of the tabbed version would be the Notepad++ Preferences UI. Many other programs use a similar scheme.
The best way to get a UI that makes sense is to follow Joel's advice:
Eat your own dog food.
Do it a few times to your own UI, and you'll notice some things you didnt think of intially.
I've found that a really good test is getting someone non-technical to use your GUI. Watching someone use it for 5-10mins normally gives me a very good idea about what is/isn't easier to understand.
This series by Joel Spolsky is a pretty good read and Jakob Nielsen's stuff Usability and Web Design is pretty useful.
Specific rules I try and use are:
Put items in logical groups
Line everything up
Use sensible images/icons
Spend 5-10 mins thinking through why things are the way there are
Only use words that make sense to the user not to you!
Start from the setup/config UI of an existing application that you feel is both simple and usable.
Most tenants/cardinal rules apply to UI in general and fill hundreds and hundreds of pages in UI design and HCI books, so you probably want to just work your way by example for now, while trying to capitalize on existing user experience (habits), i.e. obeying the rule of "least surprise": e.g. if your application is a Windows application, use the Installation Wizard pattern, if it's an ncurses app for a particular flavor of *nix follow the style of that particular OS's actual installation UI, etc.
You might be interested in the book "Don't Make Me Think," (author's web site) or "About Face 3.0". Both come highly recommended for reading about how to design interfaces.