On Dec 10, 2007 4:40 PM, Mimi Yin <[EMAIL PROTECTED]> wrote: > > On Dec 9, 2007, at 6:35 PM, hank williams wrote: > The interface designer's critical task is to support and reinforce the users > understanding of the data model > > Thank you Hank for articulating this. I think this may be at the core of > issues you are running into. >
Mimi, What you are saying is I am not mean to understand the data model, and that what is important is that the software matches my "workflow". I strongly disagree with this. I believe users must have a model in their mind that matches how the software is modeled. For background on this and a far more articulate explanation than I can provide of why, I look to Bruce Tognazzini, and Don Norman, both at various times from Apple, and what I would consider to be the father's of modern software and product design. Specifically check out this article. Its long but, in my view brilliant and totally on point. http://www.asktog.com/columns/069ScottAdamsMeltdown.html > More often than not, aiming for 'useful' results in concepts and > functionality that are 'ambiguous' and 'inconsistent' in the way it works. With all due respect Mimi, I *strongly* disagree with this statement. I believe excellent design is about achieving both of these things and that it can indeed be done in consistent and unambiguous ways. > believe this is because user workflows are complicated and full of > exceptions. This is true. This is why you layer user interfaces. Surprisingly and fortunately however, workflows are often > twisted and gnarly in highly consistent ways. In the end, I think it boils > down to how you're looking at the problem: From the perspective of trying to > understanding the inner workings of the tool; or from the perspective of > trying to understand the workflows. You *must* understand the tool, at least at a basic level, for it to work in your workflow. The 2 are by no means mutually > exclusive. I'm not proposing a binary view of product design. It's more a > matter of where you start. > > So in Chandler, if there are UI elements that are unfamiliar, or kinda of > familiar, but not quite the same as what you're used to, the intent is to > communicate how we've in some cases tweaked existing functionality to more > closely map to usage patterns and in other cases completely up-ended > existing models. > > I think 'overlays' and 'collections' in Chandler are examples of where we've > tweaked existing functionality. > + Overlays are called overlays and have special widgets because they don't > behave the same as checkbox, multi-selection. But they should behave the same. I don't understand the new problem you are trying to solve here, or the benefit that uniqueness brings to the table here. > + Collections are called collections because unlike 'tags', they aren't mean > to be used as a way to 'describe' you data and unlike 'categories', they > aren't intended to be used as a way of taxonomizing your data. As far as I can tell, collections *are* a way of taxonomizing your data, since the data can be in more than one collection. I think this is the text book definition for taxonomy, even though it is flat. Contexts are > probably the closest thing. But we chose 'Collection' because it emphasizes > the 'action-verb' aspect of the feature: Collect the stuff you want to see > in 1 view, as opposed to the end-result of the feature: That view will > become one of the contexts you sit in when managing your information. > I no longer have a problem with the word collection, though it *is* a taxonomy. > Triage and Stamping are examples of ways in which I feel we've up-ended > existing models. > > Your feedback highlights the difficult situation in which we find ourselves. > > We're trying to challenge, break and improve upon existing ways of solving > problems. But I am not clear what is new with triage. It is nothing more than sorting by priority with some new jargon. At the same time, we're disappointed that Chandler isn't > immediately usable, isn't as immediately usable as an nth generation > iteration on an existing approach. But the nature of the beast is that there > are always trade-offs between innovation and usability and I fear that > trying to optimize for both within the confines of the interface design will > turn into an exercise in futility. > Wow. This really sounds like you are resigned to the negative state of the feedback. I do not agree that you cannot innovate and have people "get it". You have some already great work in this area (the mockups I saw) I don't know why you are opposed to implementing the great user interface work you have already done. > > Even the fairly evolutionary transition from OS 9 to OS X threw people off > for a long time. New improvements were considered unnecessarily confusing. I > felt that way for a long time. But really it was a matter of readjusting my > own expectations and breaking old usage patterns to form new improved ones > around what OS X had to offer. > I get your point here. And if I felt that you were really solving new problems with a breakthrough new strategy I would *totally* agree. But I have yet to hear an argument of what the actual benefits of these differences are. Moreover, you are starting in a hole because there is not that much interest in chandler. It is important to get people to play with it and to get it right away. Then you lead them into the depth of the system. > > The takeaway for me is: Now that we've gotten Preview out the door, we need > to turn our attention to helping people up the usability ramp with > refinements to the interface where appropriate, better messaging, better > demos and active user support on mailing lists and IRC. This is noble. But Mimi, as background, I have been programming for 30 years. I wrote DayMaker one of the first PIMs for the mac in '90. We pioneered the concept of categorization. Since that time I have designed lots more software. As a hobby I have probably over the last few years studied dozens of PIMs. My point is not that I am anything great (what have I done for you lately) but that I get this stuff. It should not be hard for me. I am not just some noob user. And my point is *I am confused*. If I am confused, messaging, demos, and active user support are not enough for really almost anyone. In 2007, end user software that requires a manual, support, mailing lists, etc cannot succeed because no one has the time. I implore you to be a bit more open than the tone of this note suggests. I understand this kind of stuff is never fun to hear with your baby, and I apologize for my "pull no punches" tone, but I only want for you guys to succeed. You guys are so close. Hank _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Design" mailing list http://lists.osafoundation.org/mailman/listinfo/design
