I work in a small and young team of developers and we have problems that we are not sure how to solve.
On previous projects every developer have been working on tasks that were based on use cases. So, upon setting the system architecture, each team member worked on user interface and business logic of tasks assigned to him.
This kind of organization gave us the problems with UI. Each developer had his own logic about how UI should look like, where buttons should be, etc etc... and even if we've had one css designer a lot of refactoring had to be done in order to make web site to look compactly.
How do you deal with this issue?
Do you split tasks based on layer, not on whole use case?
Do you use some technical solution to achieve this or is it just written standard that every developer need to follow?
Thanks
Everyone has their own style and it would be difficult and a waste of time to define a standard that would get everyone to draw the UI in a consistent manner. Instead, elect your best UI designer to do what he does best and design the UI for the whole system. Funneling all UI changes through the designer would be difficult so just let your developers "mess it up" as they implement new use cases and just have your designer clean it up before the release. It shouldn't be hard for him/her to rearrange the existing forms and bring some consistency back to the UI.
I've found this 12 Standard Screen Patterns article very useful.
A solution might be to create sketches of all screens of your application, have them reviewed by an ergonomy-expert to correct the biggest mistakes, and, only then, give them to your developpers.
This way, they would know how the screens they are developping should look like -- there will still be a couple of differences in the end, but those should not be "big differences", and should be eaiser to fix.
And this would mean not each developper has to imagine what the perfect screen would look like : each one of those would be coherent with the others.
Adopt the tried and tested MVC system, let the view be decoupled from the business logic. Then ask a UI designer to produce sketches and work to that. UI's are something best done top-down from my experience. The user gets an overall view before being presented with all the details, defining and capturing this hierarchy makes good UI's. Coding of business logic is done as you mentioned on a use-case basis, mostly bottom-up and this is where the code falls out of sync with the UI.
Designate one person (preferably someone with graphic design experience, even if they're not really a programmer) and give them the authority to make cosmetic changes to all forms, pages and controls at any time, and have them be responsible for the overall look and feel of the application.
As far as metrics go, keep track of how much time this one person has to spend "fixing" each programmer's work, and make sure the programmers are aware of these numbers. The idea is to encourage them to make their stuff look like it should from the beginning, but also not to do weird things based on what they think stuff should look like. I've had to spend more time undoing my coworkers' bizarre design choices than anything else.
Don't be afraid to have outside sources review the design work of each programmer. It's very common for programmers to 1) produce horrible-looking UIs, and 2) believe the UIs look fantastic. You should do what the Army does with boot camp: break them down completely right from the start, so that you can build them back up again the right way.
Part of the problem with creating your own written standard is that while well meaning, there could be mistakes or better ways to do things than what's been standardized. For example, where I work, the standardized cancel button does nothing when you click on it (it's been wired to Reset).
Instead, I recommend choosing existing standards, such as The Macintosh Human Interface Guidelines or Windows User Experience Interaction Guidelines. Even if the standard is wrong, it's rarely profitable to deviate from widely established conventions.
Then pick up some good books for the developers, such as "Designing Interfaces: Patterns for Effective Interaction Design". Good user interface design is partially a matter of good taste, and while not every developer will be interested in the subject, it's in your best interest to help them improve.
Next, empower your QA team to file bugs when the interface for one product is inconsistent with another. The developer can then either standardize or justify the deviation if he has a reason. We do this; it works pretty well.
Lastly, go over your existing products and get a consensus on how their interfaces should be unified. Bring in (and keep) a usability expert if you can. I've seen good ones do amazing work.
There really is no clear solution for how to deal with UI problems. There are however several approaches one can take to combat the problem of having things become too complicated:
Use cases are usually cross disciplinary in nature, thus the responsibility to get a use case done should be split between the people who can implement it properly. Programmer and designer type of people need to cooperate.
Everyone in the team needs to keep in mind seperation of concerns, i.e. things that can be seperated must be kept that way preferably as early as possible. There are so many ways to do this: e.g. apply MVC pattern in your project (which is a very wide way to put it). Presentation and logic should be seperate so that changes in one layer should not affect the other.
Someone needs to be responsible for the overall UI design so it is consistent throughout the application. Preferably someone who is both a graphic designer and has some insight in usability. UI design is something that needs to be planned along with the use cases and revised constantly as development goes on. Consistent UI is very important and developers need to be on board on it.
Related
I really want to create a stunning-looking GUI desktop application that looks like, for example:
Mac OS X interface
Picasa desktop client on windows
IPhone apps
Office 2007
I've mostly been programming GUI using Qt/Swing/WinForm
and I'm tired of creating so plain looking GUI, lol.
So I was thinking about diving into stuff like:
jQuery
WPF/C#
iPhone SDK
Silverlight
Adobe Air/Flex
Just to get some ideas on how to create really cool looking UI.
Does that sound like a good list? Any developers here that could share what platform they use to create very cool looking desktop app?
On a sidenote, I really wonder what developers at Apple / Microsoft use to develop their own cool-looking software.
EDIT
A lot of responses talk about the importance of usability over "cool-looking"..
I totally agree that usability and simplicity are the most important aspects of user interface design. I've been doing GUI development for a while now (> 3 years), so that I understand.
But using cool-looking UI also improves user experience + it could make big difference on whether or not your software sells.
I mean, otherwise why would Microsoft/Apple try to make their OS UI look "cooler" everytime there's a new version? Why would websites like pragprog.com, or versionsapp.com. make their websites look like that? Basically you kill 2 birds with one stone: stunnning-looking UI + super usability (because it looks simple and intuitive).
That is what I'm striving for. And as far as I know, I cannot achieve that using Qt/Winform. Most of the books I have read just show you how to make average-looking (read: 1990's) UI. I want to learn how to create cool-looking UI. And the only place I see cool-looking UIs these days are the technology I list above. I'm not enamored with any technology; but I just want to know how things are done in other technology to see if I could apply them to the technology I'm using, or see if I could use those technology in my line of work.
An example: if I were to pick between this UI and this UI, I probably would pick the latter, if just based on looks alone.
Functionally, they are just the same UI; they both allow you to keep track of your time. They both contain buttons and textboxes, etc. But the fact that they look different, also differentiate them in terms of attractiveness.
So in all, I think the "ice on the cake" is very important. I would say it's the thing you strive for after you are certain you have a totally intuitive, usable UI.
I think that the major reason many people suck at designing interfaces is that they consider them to be graphic design. It is not. The core of creating a good user interface is a bit like creating a good API – the interface has to be conceptually consistent, hard to misuse, easy for common tasks.
Wanting to design something cool because you are “tired of plain GUI” is a perfect recipe for disaster. If for nothing else then because consistency is a crucial part of a good UI. If each application wanted to stay out of the crowd, the whole thing would be an unusable mess.
It is almost unfortunate that Mac OS X looks that good, because then people start to think you can create a good interface by animating it or sprinkling some graphics on the top of it. The graphical part, the “cool” of the design is just the icing on the cake. If you really want to design good interfaces, stay true to the environment, respect local human interface guidelines. And maybe read Apple’s Human Interface Guidelines to get a feeling where the problems are and what can be done to solve them.
I know this sounds much more boring than filling gradients in Photoshop, but it’s the only right approach to take if you really want to create a top-notch interface.
the key to a stunning graphical user interface is twofold:
it still has to be useful to the users, and that involves a lot of hard work, study, paper prototypes, user interviews, usability testing, et al.
hire a really really good graphic artist
Neither step is optional. If you -the programmer- also happen to be a really good graphic artist, that's fine - but the vast majority are not, and no amount of fancy tools and photoshop tutorials will replace the talent and training that real artists bring to the table.
I don't mean to sound harsh, but most programmers are terrible GUI designers. Myself included. It's ok to leave art to the pros. ;-)
I'm all for WPF/Silverlight, but it really about the platform that you need to support.
The real deal is your own talent, as WPF is a powerful tool, if you ain't got the talent to use it, it will look like improved winforms. (Also check out the Expression Studio from MS - which enhance what you can get out of WPF).
If you want to know more about UI you can read this books:
About Face 3: The Essentials of Interaction Design
The Inmates Are Running the Asylum
UI development is not about technologies. In some cases console is the best solution.
We can get commercial GUI add-ons like Telerik which also supports Mono as well.
Regardless of the UI technology, you will of course be well-served to adopt a programming style where the look and logic of the app are as decoupled as possible. This allows you maximal flexibility to design and evolve the look of your application (the View) while potentially requiring very few code changes in the back-end (the Model or ViewModel).
While possible using all UI technologies, it's particularly easy to execute this in the case of WPF/Silverlight/Moonlight via the MVVM programming style, due to the succinctness of databinding (very little boilerplate "glue" code).
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
Hey all. I would like to get some insight on a question that I have been trying to find some information about. If you are the solo developer that is building a project from ground up, how do you manage the project? In the past, I have worked on a few personal projects that have grown into fairly large projects. In almost all of those projects, I have tried to wear the hats of all the roles that would normally be in place during a normal software development project (i.e. Product Owner, developer, architect, tester, etc.). It seems that when I leave the project for some time and come back, it is extremely hard to get back into the rhythm of what I was doing. So with that, I have some questions:
If I know the requirements (at this
current time), do I record them
anyways? If so, how do I go about
doing this, and how do I manage these
requirements? Product backlog,
features list, etc?
If this is the case, are full blown product backlogs or use cases a little overkill?
How does one efficiently appropriate
his/her time to each respective role?
What would be a normal flow of events
that one would follow? Start coding
immediately, write down user
stories/use cases, then go into
OOA/D?
What diagramming/modeling would be sufficient for this level? Domain model, class diagram, etc?
Basically, I was curious how everyone out there in the SO community would go about developing a project from inception to deployment when you are the lone, solo developer. What steps, documentation, and other project related activities are needed to help bring this project from an impractical, hobby project to something more professional? Any help, references, or suggestions would be greatly appreciated. Thanks in advance.
The most difficult part, I have found, about developing solo is that it's just tough to keep yourself driving forward. Even if you're doing this to make a living (AKA, running your own software business), unless you have pressing needs (AKA, you're going to starve if you don't make money) it can be difficult to sit down and just code.
From your perspective, I would recommend following good software practices where it makes sense to. For example, if I were a solo software developer, I would have no reason to create a collaborative development environment. All I really need is an SVN server, my IDE, and a place to record documentation (might setup a wiki or a website or something). I would personally create a realistic schedule to follow and would work on sticking to that.
As for level of effort of documentation, that really depends on you and the product you are developing. For example, I would definitely recommend recording your requirements. Unless your product is trivial, there is no way you'll remember them all and why you wanted certain ones over others. Managing a full backlog, however, can be a job in and of itself. In the solo programmer case this may not make sense.
Basically, the point I'm trying to get across (and should be followed with every project - not just in this case) is have just enough management that makes sense. The rest should be focused on the work and the development of the product.
Something else you may want to look into is reading this - Agile Programming Works for the Solo Developer. There are other, similar, articles out there. Might give you some good thoughts.
If I know the requirements (at this
current time), do I record them
anyways? If so, how do I go about
doing this, and how do I manage these
requirements? Product backlog,
features list, etc?
I have two lists of features:
A high-level view which states the scope of the finished product
A list of the features which I'm implementing in this iteration
Because I don't need to communicate it to other people (yet) I tend to write down the things that I don't know about the project (if I already know it there's no need to write it down): it's when it gets too complicated, or when there are details which I haven't defined but need to define, that I start to define them in writing.
I did however try to investigate/make a business-case for the project before starting coding.
How does one efficiently appropriate
his/her time to each respective role?
I did non-programmer, product-owner thinking at times when I had to be away from the computer anyway.
Apart from that, my cycle is:
Implement more functionality
Integration-test it
[repeat as above]
Every 3 to 6 months I compare the new-functionality-accomplished against my estimated schedule, and then recalibrate: i.e., make a new list of the highest-priority features to implement in the next few months.
What would be a normal flow of events
that one would follow? Start coding
immediately, write down user
stories/use cases, then go into OOA/D?
I started with working part-time or in my spare time, to make sure that I had:
Understood the required functionality
Made significant architectural decisions
Written any throw-away prototypes as necessary to learn new technology
After that I was ready to start developing full-time.
What diagramming/modeling would be sufficient for this level? Domain model, class diagram, etc?
I'm not using diagrams at all (except for sketches of the UI). By structuring the code, and refactoring, I'm able to know/remember/rediscover/decide which software components implement what functionality.
It seems that when I leave the project
for some time and come back, it is
extremely hard to get back into the
rhythm of what I was doing.
You need to comment your code more. If you leave the code, come back in two weeks, and can't remember how the code works, you need more comments.
If I know the requirements (at this
current time), do I record them
anyways?
Yes, for the same reasons stated above.
how do I manage these requirements?
A feature list is OK, provided you have enough detail in each feature to jog your memory.
How does one efficiently appropriate
his/her time to each respective role?
Break down each feature into smaller and smaller tasks, until you feel like you can do each task in a half day or less.
What would be a normal flow of events
that one would follow?
That depends on your development style. In general I would follow a clear but simple architecture, avail yourself of software patterns where practical, and provide adequate unit tests for your code as you go.
What diagramming/modeling would be
sufficient for this level?
Sufficient diagramming/modeling to make the project clear in your head.
What steps, documentation, and other
project related activities are needed
to help bring this project from an
impractical, hobby project to
something more professional?
Other than what I have already mentioned, make sure you have a good source control system and daily backups in place.
Good luck!
If you believe there is a chance that you're going to work on the project for some amount of time, leave it, and then come back to it at a later date...your best bet is to treat the documentation for the project the same as if you were working with a large team.
That means documenting requirements (even if they're from yourself), writing use cases (if functionality is going to be complex, otherwise some other form of documentation could suffice), and some level of UML diagraming (or other domain specific diagram) which could include activity diagrams/class diagrams/etc.
That way, when you leave the project for some amount of time, you can come back to a well documented idea and pick up where you left off.
As a side note, I try to do the majority of those things no matter what...that way if I ever find somebody interested in working on the project with me, I can get them up to speed quickly and get them on board with my ideas.
This is how I work, YMMV:
Keep a spreadsheet for high level of everything - list of your projects, and some top-level items/todos/reminders
Create a "project" folder for each product/project you have or work on, and create a strucuture to contain documentation and code for the project.
Keep a top-level "catch-all" document for each project, in the root of this folder. Keep you ideas, research, notes etc in this doc.
Then if you want to get organized, keep an MS project file (or similar) and plot out timelines for the various steps in each project. This is good for tracking progress on each project and make sure you arent forgetting anything. Basically keeps you honest with yourself.
And if you need to track progress on project work you are doing for clients, I understand Basecamp is a good solution for this. I am currently evaluating it for my own company. See www.basecamphq.com
Even as a solo developer, you should document at least the overall features of your project, and then the requirements for the particular feature you are working to complete, and then maybe produce a short pseudo-code for the functionality you're currently working on.
That way, if you do end up breaking away from that project, you can get back to it and see where you're up to easily enough. It's also pointless getting too far ahead of yourself with details for this same reason.
It's also a neat motivational tool for a solo developer - getting through and ticking things off is a way to show progress - something that you can start to feel you're not making when you're chewing through a couple of thousand lines of code and it seems like you're still miles away from actually having 'module x' completed.
Lastly - with regards to code comments - I at least try and fill out what actions/behaviour a new function should have in an outline, and then write the code in between the comments. Also, it is useful having plain English explanations of why you're branching in an if/else to support the logic in the condition...
I belive that better results in solo development one can achive with appropriate tools support and tasks that compensate lack of ohers people and help to organize working time. Any tool that generate metada with minimal create time cost describing your software is helpful.
VCS and tools for tracking user actity/code changes history - very important is to add good commit messages
mind-mapping tools for storing project related data (e.g. XMind), blacboard is useful too :)
time tracking tools (e.g. Toggl.com)
write a lot of acceptance test and use acceptance testing frameworks
Of course these clues also fits in non solo development :)
As a lone developer, I've found that your time is very expensive. This means that you have to balance sustainability and momentum - even though you are just one guy, you have to do things so that the you six months from now can go back and look at old stuff without wasting time, without spending so much time maintaining the systems that it compromises your flow.
Your question suggests that you are thinking in terms of fairly heavyweight tools and processes, but the 80/20 rule applies - for example, you can nail documentation well enough by TDD, using the doc tools of your platform to generate API docs, plus a Wiki for specs, lists, etc.
In that vein, I would suggest that you choose your platform carefully. The question about modelling suggests that you are using a platform that produce a lot of code and artifacts, but you may be able to get most of the functionality for much less management overhead elsewhere. Today I'm working on a .NET Web app that I wrote "the right way", but now realize that I could have delivered the same functionality much more efficiently in this case by using PHP with a PHP MVC framework to keep a clean structure.
Specific tools that I'd recommend:
A distributed version control system (much less overhead than centralized)
The most lightweight platform that you can use that has good tooling
A Wiki to easily capture and maintain small and large bits of content
Whatever testing framework that you can use, right from the start of the project
A lightweight TODO list system that you can access from anywhere
I used to work on a very small team (one dba and one C# developer). Even then I found it very useful to have written requirements, formal tests, source control and bug tracking (we used bug tracking for our features as well as bugs). It helped us to not forget anything and a year later when you were doing maintenance, you had something to research though to help you undersatnd what you did. Plus when the two of us left (as most people eventually move on) there was documentation there for the next person.
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.
I find that most of microsoft's new programs are very hard to use.
Microsoft Office 2007 (word especially) I find to be hard to use.
Microsoft IIS 7.0 is a PAIN, I never remember which icon to click on, things are just to cluttered and hard to find.
As a programmer, we have to design according to what people are used too, what exactly is MS telling us to do?
we have to design according to what people are used too
Well that's a slight misconception. You're not wrong that people familiar with something will appreciate the interface remaining familiar, but not all change is bad. You have to weigh the power of the change up against the harm it does to veteran users.
Lets take Office 2007 as an example.
The ribbon interface is a huge departure from the interface Office has used for as long as I can remember but there is sound logic behind it.
User functions are grouped by activity and it's very easy to change which set of functions you're looking at.
They're also contextual so some thing only show up when you're on a table or an image (etc).
These both help keep the clutter down - something really quite useful as these apps grow in feature-sets. Rather than spending hours choosing and customising a set of toolbars, you have access to everything through the tabs.
And Microsoft did this all the right way. They tested the interface on lots and lots of real people. They listened to see what worked and what they should fix or drop. They also kept some legacy keyboard shortcuts for seasoned pros.
The redesign effort was targeted at making life easier on beginner and intermediate -level users. Mission accomplished. The problem you're having is overcoming your familiarity but I can't be more helpful than say: It'll happen in time, but you'll manage it in the end.
Look, I'm just a simple caveman, scared by your post-modern architectures and vroom vroom machines go honk. I'm used to the simple life of the paleolithic era; charcoal cave paintings and bone-based technology. I can't make heads or tails of your fancy ribbon UIs and pointy-clicky icons. That's why I'm never upgrading from DOS. The old ways were always the best, and learning new ones bad like fire.
Well, Microsoft has to balance this. On one side, users scream for new features and change-for-change's sake in a lot of MS software. On the other, lack of backwards compatibility (including subjective UI compatibility) is a deal breaker. Really no way to win there.
That said, I don't think we need to design according to what people are used to; neither does Microsoft. Change will never happen if we just do what has always been done before. IIS is not developed for programmers; it's developed for IT people. And the new interface serves them well. Likewise, Office is designed for office drones, not programmers, and the new Office is very discoverable for that particular group.
I think they take a while to get used to, but I do like them. (Althought I will fully admit I am a mac person and I like the mac UI a lot better).
The biggest thing I've seen about the UI that is difficult is the fact that it is so much different from previous versions (I'm talking about the current version of Office). That seems to be where most of the rub is.
The rule I was taught about UI design is that things need to be familiar to the user (that's really is what makes it "intuitive"). MS broke that rule ......but from a business perspective they are allowed a little leeway when doing this simply because they control so much of the market share. Ultimately, they know that a radical change won't cause a loss of much market share because for most people and businesses there isn't a real viable alternative. (I know there is open office, but migrating a mid to large office to it will cost as much money or more as it will to just continue using the same product).
Do we have to design according to what people are used to, yes we kinda do. Does this mean we have to make it look like what MS is doing now, not necessarily. What we have to do is create a design the users can relate to. They have to be able to make a jump of logic from what they know already to using the products we create. If not, they most likely won't use the application unless they are absolutely forced to.
User interface and user experience are totally separate concepts. (Simon Guest; User Interface Blog.)
Microsoft did quite a bit of research in the raw usability of Office 2007, and found that while there is a learning curve for people like yourself, or me, who are experts in the tool, newer users and non-experts experienced much greater discoverability of more advanced features, and wound up using more of the application's features and power. Yes, there is a learning curve if you knew Office 2003 inside-out (which, frankly, few of us really did).
Now I'm not making apologies -- Microsoft's UIs haven't always been easy to use, and sometimes they fail miserably. (Personally I think not standardizing all of their office products on the Ribbon is a classic example -- there's a large context switch in my brain when I open Project or Visio, compared to when I open Word.)
As for what developers are "supposed" to do: Bear in mind that the ribbon isn't ideal for every scenario. If you're using it as a glorified, prettified toolbar, it's being used incorrectly. It's designed to help you organize literally hundreds (if not thousands) of commands in a way that makes them discoverable to your end user. It's supposed to reinforce the traditional experience of discovering the abilities of your application in a safe way (see any edition of About Face), when the depth of your application is too great to function within menus.
Aside from that, bear in mind that we should generally be making the most appropriate UI for our own audience, as Microsoft is attempting to do for its own audience. Again, we may find these things more difficult to use, as we are used to doing things a set way -- but it's the right thing (typically) for Microsoft to do. Remember that we programmers are not the target users of most UI. (How many of us turn off visual themes, for example? Now how many normal end users? BTW, I don't fall in that camp; I'm one of the few who actually finds Vista moderately attractive.)
Again, at the end of the day, what Microsoft does matters only to the extent that it becomes what your users expect, and then only if you can't educate them that "your way" is better. In any event, if usability is truly critical for you and your users, it's time to invest in usability testing and ensure that your application really is as usable as you think it is. And start reading usability sites. (You don't have to agree with them all, but understand them.) Here are some samples:
AskTog (Bruce Tognazzini, inactive but the archives are a treasure trove)
UseIt (Jakob Nielsen)
jnd.org (Don Norman)
Office User Interface Blog (Jensen Harris)
Microsoft Windows User Experience Interaction Guidelines (The holy word on Windows)
It's interesting because there was a lot of talk about the usability testing that went into the design of the Ribbon controls, but along with almost everyone else I know I find them very difficult to use. I keep losing controls that I need and not being able to get them back until I've cycled through another three or four document views looking for them. I instinctively move my mouse to menus that no longer exist.
I wonder if they would be easier to someone not accustomed to the earlier office products- maybe this is who they did their usability testing with. I don't think the design of the new interfaces is bad as such, but it is different enough that for those of us who don't spend our whole time staring at Office but have been using the product for a long time it makes life difficult. I guess most real power-users would be doing most tasks from keystrokes anyway which presumably haven't changed too much.
The business problem is really that they need an incentive to upgrade and so they keep adding new features ( who do you know that uses all the features of Word ) and then they need to find ways to present those without making the application impossibly cluttered, which was certainly happening in the previous version of Office.
I'm not sure what we take from this as developers- maybe it's that we should design for usability from the start or find ways to make the transition between old and new functionality as easy as possible for our existing users.
Microsoft IIS 7.0 is a PAIN
I'm relieved to hear that others have found the new IIS UI a challenge. I stumbled into it without being forewarned, and was completely discombobulated. There is so much clicking around. You have to memorize where the feature is, or click and click. I don't know of a way to see all of the IIS settings at once (not that you could before, either, but at least you could stay in the single tabbed dialog).
I think it is really hard to adapt to an entirely new UI when you are so familiar with the old one. I am similarly disoriented by the ribbon menus. More clicking around to find the features. And not everything is in the ribbon. Some is in menus accessible from other entry points, such as file properties.
For new users who never saw the old UIs, it probably isn't so much of a problem.
I guess what I really dislike is having to spend the time learning the new UI, at the least convenient time. There is an immediate loss of productivity when you have to learn the new UI. You can't just drop into IIS, configure the website, and be on your way. The first few times, it's going to take a lot longer. Maybe with growing familiarity, we will come to like the new UIs better.
I wish they had given the option to show the menus for us old fuddy duddies.
I had a meeting with one of the Microsoft Office guys last year when I brought up the same points. His point was that the number of features had grown so much that a new method of displaying them was required. I was not entirely convinced and found it amusing that Microsoft are so touchy about the problem that he had a very nice, well-prepared PowerPoint presentation to give to try and explain it.
MS is trying to give users more power by being able to click this to do this or that and try to make what others may see as very advanced functions simpler to use and more powerful than the previous ones. I remember going from IIS 3.0 to 4.0 where suddenly, there are all these new buttons to click and things are different but it is kind of better. I also remember going from Windows 3.11 to 95 having its own shock of updating things.
Did you ever try watching a movie on VHS and on DVD or go from cassette to CD? Remember how the DVD suddenly had all these new features like chapters, no need to rewind, bonus features that you could just go to and not have to fast forward to find? Similarly how a CD organized things so much better than a cassette? Another point would be to look at TVs where it used to be very few options on a TV: There were 2 dials, the power and volume where combined into one place, and a few other knobs were all we had but now you have TVs where you can store favorites, closed captioning options, sound setting, and color style that could scare some people that remember the old days where you had to physically pull a knob to turn on the machine.
I find that most of microsoft's new
programs are very hard to use.
If you feel so, do yourself a favor and change to Mac. I did it and wont go back to windows. So much time wasted to achieve little things with Windows.
And Apple has Style Guides for GUIs. You dont have to stick to them, but as far as I can tell most developers do.
To prevent a Mac-Windows-Flamewar I would like to point out that this is totally my opinion. Please dear Windows user, do not feel attacked by my opinion.
This is a broad question, so let me narrow it a bit. I am a graphic designer entering the world of web design. I'm not totally green in this field, but I know enough to know that I have a lot to learn. From friends and from posts on this site I realize there is often a harmful disconnect between design and development.
I'm getting ready to place a client log-in/password "portal" on my website. Nothing fancy, just enough to provide some sound mind for my clients and a space for secure download of imagery. I am only handling the look and feel of this one, nothing more. What potential pitfalls should I know about, on my end, to avoid making the development end hairy?
And of course any other nuggets of wisdom are appreciated too. Thanks!
Perhaps the worst mistake that many designers make when working with developers is to assume that developers aren't creative, and that we couldn't possibly have any good ideas or inputs into the design. The fallacy of this is obvious because what we do all day, every day, is create things. It's taken for granted that designers can raise bugs against developers when our code doesn't represent the design exactly, yet many designers get very touchy when we raise suggestions about how their design could be improved even in minor ways. Sometimes the suggestions may not be suitable, but occasionally you might be able to improve your design.
In addition, I have frequently found that designers under-estimate the capabilities of developers to achieve what they want, so will sometimes suggest a simpler alternative. By opening up the dialog and giving a couple of options like a minimum one and an ideal one, you might be surprised that you can have elements of the ideal one, or all of it, or even something better as you discuss what actually can be achieved (sometimes what seems hard to achieve to a designer seems easy to the dev, and vice versa, because they are different disciplines). Of course the converse is true and you might be aiming too high, so you need to find that out as well.
In summary - you're absolutely right that any disconnect between design and dev is detrimental both to morale and the final product. So talk to the devs as soon as you have initial designs, and keep a good two-way dialog open.
I am a web developer, so I'm answering this from my viewpoint. There is really no serious pitfall as long as developer and designer understand each other. One tries to make websites look as attractive as possible, while the other tries to make the look of the website as close to the design as possible.
So when I'm asked to do the impossible, (like replacing the browser's default scrollbar with an animated image of a cat) I'll just tell the designer that it can't be done, the reasons for that, and suggest possible alternatives (Flash ?). After that being said, I expect the designer to understand and cooperate with me to choose the best alternative, not suddenly turning into grumpy mode or something.
A little basic knowledge of the developer's work would help, too.
Some ideas that may smooth the process :
Talk to the developers directly and ask if they have any specific requirements. Different platforms have different needs and requirements. Communication is important.
Get the basics of good HTML and CSS down. There are many references but you can try A List Apart as a starting point.