| I think this issue of relevance also has relevance to this notion of adaptive software, or software that changes with you as your data management and organizational needs evolve over time.
The guiding principle is that the user is never presented with options that are irrelevant. They are never asked to make a decision before they are ready to decide.
Entourage asks: is this grouping a Project grouping? or a Category grouping or just a normal Folder grouping? When you're trying to file that first email into a new grouping, how are you supposed to know which of these things will turn out to be the right affordance for you?
In other words, the ability to have Project groupings should be available to you WHEN the notion of a Project is relevant to your needs.
Mimi On Oct 1, 2005, at 8:21 AM, Daniel Vareika wrote: Philippe:
You have nailed it once again (at least for me).
Relevancy is in fact an issue.
I liked specially your explanation of the complex perceived as simple and the simple perceived as complex.
Regarding this last one, you say that programing a VCR is irrelevant or at least irrelevant for the user.
I only disagree on the term, I believe it is a tedious chore not irrelevant.
Simply a bad implementation of a design of a need.
When at first the idea was to be able to program your vcr so as not to miss a scene of your favorite novel or sport.
The thing is that it was not practical, then other (better) alternatives appeared: for example the same show on a different time so as you did not miss it, etc..
Only if they had implemented some kind of clock, self battery in the design, maybe you would not have to worry and in the past (not now that there are other alternatives) we would have used it more.
The problem to my eyes was the whole user experience:
to program the clock
to program the show (that sometimes didn´t even start on time and end on time)
to search for the show later on
watch it with a lousy quality
Conclusion: frustration => never using it again
So there was a problem of implementation (design) and appearance of other better alternatives.
I think we could improve the usalibility of our software by thinking more about what's relevant to our users I agree and disagree on this matter.
Why I agree.
Through the course of this years incidentally I have been teaching (and using) both Adobe Illustrator and Adobe Photoshop, both from the very first implementations (1.0).
I have seen them become bloated sometimes, redesigned the UI some others.
I have seen better implementations, and have suffered worst incarnations.
As a matter of fact, to teach Photoshop (I did it till ver. 6.0) took more time for the average than it did in version 4.0.
It was also more difficult for the user (and the teacher) to grab (and explain) the key concepts that were essential as good solid foundations.
Maybe that is why we now have Photoshop CS2 and Photoshop Elements 4.0, one for the power user and one for the novice, though this are more different targets.
Note: please don´t think that I am implying that there should be 2 or more versions of Chandler for that matter.
Why I disagree.
A marketing division (of the old school) would make a poll and would come up with what people need.
From the result of the poll the design team would react and try to add what the poll indicates.
What we have seen through out time is that for sure a poll is good for measuring what is not working or useful, but I believe that it is not good at finding new solutions or features. They simply cannot evaluate something that has not been designed, and it is not their role.
Polls in my opinion are good for measuring existing provable concepts for that matter.
Disruptive technologies or designs are rarely or never the result of a poll.
Are more the search or individuals with a profound knowledge, a design ability, and sometimes mostly a need to be fullfiled.
The inner knowledge that there must be a better way either through revolution and or evolution.
Good examples for this are:
Lotus 123
Mac OS (1984)
OXO Good Grips (could not find the full interesting story)
Lindberg Air Titanium eye wear (see History is worth reading)
I am sure Philippe that what you meant is in that thin line between being able to interpret what the user (the majority) really needs that what all the people would want.
I am also sure that you are in the same quest for either evolution or revolution depending which one fits better for Chandler and the user.
Yours,
Daniel
Philippe Bossut wrote: Interesting read Mimi. I have to agree that adaptation and evolution are 2 attributes that very few softwares exhibit, actually, no desktop software I know off shows these qualities.
Another element of perceived complexity I would add is "relevancy": when you observe people using software, sometimes deceiptively simple ones, they'll tell you that they can't do this or that because it's "too complicated". Some UI gurus will tell you "make it simple" (Cooper) but that's really treating the symptom, not the disease. The root cause is that the product is perceived as too complicated because the actions the users need to perform are not perceived relevant to the objective they have in mind, they can't connect the dots between those buttons and the task at hand.
Examples:
- The complex perceived simple: driving a stick shift is complicated and takes some skills. Yet, every year, millions of teenagers master this skill because it's very relevant to their life: they really want to get out with their friends without their parents in tow... They'll do anything to get there. No teenager will tell you that driving a car is "complicated", yet, it is...
- The simple perceived complex: I have a stereo system at home with a blinking time front panel. I read the manual once and, since the setting is lost every time there's a power micro failure, I never bother to reprogram it. If you ask me (or any other owner of blinking VCR) I'll tell you it's because it's complicated. But the truth is it's because it's irrelevant: I never need to read the time on my stereo and my stereo does not need the time to be set to perform the functions I want.
If something is relevant, even if it's complex, it will work. If it's not relevant, even if it's simple, it won't.
I think we could improve the usalibility of our software by thinking more about what's relevant to our users.
Cheers,
- Philippe
Mimi Yin wrote:
Daniel, first of all I want to thank you for reading over the material so carefully. I absolutely agree that there are many ways to solve a problem and the wiki pages I posted last time were simply some ideas to help illustrate the data modeling issues we were discussing.
Your design ideas provide rich fodder for more discussion but first, I want to address this issue of complexity or it's converse: simplicity in design and my personal take on how to evaluate the complexity of Chandler's design.
http://wiki.osafoundation.org/bin/view/Journal/ComplexityIsInTheEyeOfTheBeholder
I am putting together some thoughts on your sketches in a separate mail.
On Sep 30, 2005, at 5:59 AM, Daniel Vareika wrote:
|
