On Wed, 2006-10-11 at 06:33 -0400, Ivan Krstić wrote: > Marco Pesenti Gritti wrote: > > You know what's my real worry? I'm worried that when the storage system > > will be spec'd out (or even worst implemented) we will find out it's not > > what we need to implement the user experience design. And the reason I'm > > really worried is that I *care* about it because I'm sure you guys are > > building a great piece of software. > > I wanted to release specs for the storage system a few weeks ago, but > this got sidetracked because of work on security, the docformat, and > infrastructure. > > I'm going to try very hard to release the spec before next week. That > said, I want to caution against the seemingly growing trend to consider > *everything* a part of the user experience design. I can see the appeal > in it, but it's simply misguided and incorrect. We're building a > software stack. As with any other stack, it has a top and a bottom. > Sugar is the top, and while many of the underlying levels must thus be > designed with user experience as the primary concern, the fact is that > many of the bottom layers simply don't. > > The kernel is not designed with regard to user experience. Neither is > TCP/IP. The document store is a general, relatively low-level interface > whose actual operation is largely defined by how it's used; just as you > don't think to go and implement a new NAND flash filesystem with user > experience in mind (what does that even mean?), so it's the case with > the docstore.
There are a couple issues here: 1) TCP/IP and the Kernel were written and "designed" long before computers were ubiquitous and long before people cared about the user experience for those who were non-hackers. But that only invalidates _these_ examples, not your main point. 2) Why should they _not_ be designed with regard to user experience, where the user has to interact with them directly? There's a tradeoff in the lowest levels, of course, between crappy hardware, speed, security, etc. But that doesn't mean you don't design the behavior for the user. 3) The lower layers are obviously implementation, and as such must deal with implementation difficulties and realities of the world. 4) The linux kernel is a horrible example here, because of the political pressures to be as generic as possible and work every under the sun. You simply cannot care about the user much at all in that environment, and it surely shows. 5) For any project, the user design should drive the implementation if users are the main "client" of the product. In an embeded system that has no UI, of course you don't care about the user that much! But for a system that is supposed to be used by an actual human being for the majority of the time, the human being should be the utmost concern. Why did X just recently (like, months) get autoconfiguration? Nobody should _ever_ have to pick their monitor size and refresh rate, especially on our platform. Why should I have to explicitly mount a USB drive I plug in? I plugged it in, something should happen dammit. Why does my sound not come from my USB speakers when I plug them in? I plugged them in, something should happen dammit. For most of this, it's because the people who wrote the software were writing it mostly for themselves and they knew what they were doing. These are all reasonable requests, but nobody designed the software _from_the_start_ to even think of the average user, because "average" users at the time were all technical and not many people had computers anyway. The point is that since our laptop is meant to be used by real people, we should be driving the requirements, architecture, and experience with that taking precedence over almost everything else (except possibly security, and then not in all instances). And that should filter down through the software stack. Some things you grow upward, because the technical requirements and/or limitations are such that you simply cannot do it any other way. But in this system, the lower stuff should _always_ be subservient to the users needs. If a 10 year old kid can't sit down and figure some basic thing out in 30 seconds, we've lost, and we need to change the software. Things like "how do I find my friend" or "how do I chat with my friend" or "how do I share a picture I just took with my friend" or "how do I browse the web". Not "how do I map between file type and default launch activity to open this thing" or "how do I connect to a wireless network and browse the web". Dan > In terms of my expectations, I don't think we'll have anything more than > the wiki/eBook reader using the store for B-test. This is fine: we can > move things over as necessary afterwards, and I'm happy to revisit the > docstore design decisions if -- by some series of revelations that I > can't quite fathom -- it turns out that its design is incompatible with > the 'user experience' considerations. > > Let's not make user experience into another kind of Kool-Aid. > _______________________________________________ Sugar mailing list [email protected] http://mailman.laptop.org/mailman/listinfo/sugar
