| Alec,
The goal of the Chandler in a Nutshell write-up is to describe conceptually at a very high-level what we are trying to achieve. At this point many of these concepts have not been translated into concrete specs. We would expect that concrete specs must be realistic for each dot release. Until then it's difficult to speculate how much work is really involved. There is also subtleties in the degree in which we expect some of these concepts to materialize in a 1.0 product.
That being said, we do hear your concerns about making promises and commitments that are unrealistic. I don't think there is any disagreement with that. We do however feel it's useful to have a long-term vision and communicating this is important.
Sheila On Nov 28, 2005, at 3:15 PM, Alec Flett wrote: Mimi Yin wrote: I think 5% might be kind of strong, a lot of the virtuality is already implemented:
Actually, it might be kind of strong, but I'm not sure its far off. I'll give you an assessment of the engineering work for some of the features you listed.. now this is my own pessimistic assessment but I think that it is fairly realistic given the various roadblocks that are inevitable in a project this size and ambition.
1. Bi-directional references Nothing against all the fantastic work that has been done in the repository, but honestly I think this was the "easy" part (at least in terms of hours of labor) to implement. it truly is 95% done.
2. Faceted sidebar This is no where near complete. Yes, we have 90% of the visual display, but the last 10% of the behavior that will make it "feel right" is going to take a while. So the reality, at least from my perspective, is that we're only 50% here.
3. CPIA skins allowing us to have multiple views (both summary and detail view) This is a long way from flushed out, and there are plenty of problems with the way we represent views. We have done more hard coding than you probably realize in order to achieve a calendar-centric short term vision. Our ability for supporting other types of views, or even ideas like a standalone detail view, are a ways from even proof of concept. So we've got a ways to go beyond the exact views that you see in chandler. I give us about 50% here as well.
4. Extensible schema (sort of)
We have a lot of work here, that includes schema migration - you can't do much extension of the schema if you can't migrate it, and that is going to be a big task. I'd say we're 10% done here.
I think the problem is that a lot of the work has been architectural and therefore under the covers? as in not manifested in the UI where people can really interact with it and use it.
While the architecture is the more academically interesting part, I think engineers (me included) tend to think like "well, 90% of the work is in the backend, and then we just put up the UI, which we have completely planned for in our architecture" So while you say "a lot of the work has been architectural" doesn't mean that a lot of the work that goes into Chandler 1.0 will be architectural.
In fact, I think the "hard" part (in terms of hours of labor) is the UI. And I'm not even talking about the time spent debating which aspects of the design is good or bad. End-user UI is a complex, messy thing that takes a long time to get right, just from an engineering standpoint. There are all sorts of edge cases having to do with humans, mice, keyboards, and metaphors being not-quite-perfect.
When we see a "clean and simple" design in an app like iCal, what we're looking at is a tremendous amount of painstaking labor polishing tiny behaviors - not in design, but in implementation. While we may look at Chandler 0.6 and seeing that 90% of the window is taken up by something that looks decent, I think we're actually looking at about 10% functionality in the UI.
[As an example of a seemingly minor UI issue that takes work: when you drag items between collections, we generally put a 'reference' to the item in each dropped-on collection. But in the case of the Trash, we give the appearance of the item also leaving all the other collections. There are technical details that were worked out to distinguish 'Trash' from other collections to get this behavior.. not to mention actually writing the behavior. As if that edge-case weren't enough, there are a lot of lower level collection issues that we have worked out such that items that appear in the trash don't appear in any other collection.. further, what about when you drag OUT of the trash and into another collection? We have to special case that behavior as well. There are easily 200 more issues like this before 1.0 - none huge, none intractable problems, but they take time.]
Alec
That's not to say that we don't have a lot of work to do, but I also think that our approach has always been that if we make some fundamental structural changes to the way PIMs work, we can get a really interesting "usable" PIM that early adopters will try that doesn't have all the bells and whistles of fully-developed PIMS like Outlook.
So a lot of the features that are described at a high level, like Email, are not really Email per se (as in Email a la Thunderbird), but maybe more just bare-bones email. Email simply as a mechanism for receiving and sending out information, but not Email that can replace your current client.
How to make that clear is another issue, so that is something I will have to go back to the drawing board for. It is also possible, that this kind of detail should really belong on the Roadmap and Planning pages...
Mimi On Nov 28, 2005, at 12:13 PM, Brendan O'Connor wrote: Mimi, Alec: I super agree with Alec here: 3) I had some big problems with the virtuality document. I got very confused in the first few pages, then was really wowed by the next few pages. Then I took a step back and realized I hadn't really learned what chandler actually IS. I think the last screenshot on the 11th slide was the only place I started to "get it" - but frankly I was lost long before I got there a) chandler has a history of over-promising and under-delivering. Every person I've ever met who has heard of us has been disappointed with where we are relative to the original vision. They ask me "what happened to the peer-to-peer stuff?" "why does it suck so much as an e-mail client?" - All things that OSAF made great proclamations about and then backed off from. This document describes where chandler will be in probably 2007 or 2008 - not because we don't want to be there, but because we have a LOT of code to write before we get to what you're describing. I'm really concerned about what chandler is promising to be. Slide 5 is especially compelling for a new users... but concerns me, as a member of OSAF, because we're claiming to do everything that all of these apps do, and they EACH took a team larger than ours YEARS to develop... and we're not going to be there for a LONG time. So I guess, my feeling on this is a little different. The things described in these slides are all for Version 1.0, we can have a separate conversation about whether that's actually feasible, but the party line right now, is that this is what we're shooting for.*** As for the issue of over-promising and under-delivering, I guess I see these slides and the research and designs they attempt to summary to be a 1st concrete deliverable towards realizing the "vision" of chandler. At the FLOSS open-source usability sprint I went to, we talked a lot about how usability people, testers, designers, HCI specialists...might be able to contribute in real ways to open source projects and how open source projects might come to value "things that are not code" as substantive contributions. I see your point that people will still be skeptical unless there's something working, but I think we should recognize that we have made progress from the days when Chandler was just going to be: a revolution in PIMs, but we weren't clear on what that actually meant and how that might be accomplished? I guess now we sort of know the answers to those two questions and that in itself is progress?
so it seems that these pages are documentation of osaf's progress in understanding what a PIM revolution would be. lots of design work has been done, but assume alec's right, something like 5% of the implementation work has been done. Then think of chandler 1.0 is a design project, not an implementation project (the implementation is so far off it's barely worth mentioning?) ...To ensure people get this, maybe some things like
1) Every single page needs a disclaimer that the implementation is a long, long ways off. Throw in a number like "the 0.6 calendaring chandler has 5% of this vision" to play down expectations
2) use future tense when talking about what "chandler 1.0 will do" NOT what "chandler does".
3) use "chandler 1.0" instead of just "chandler". You can download chandler today, but you can't download anything like chandler 1.0.
[like in python dev, they've used the term "python 3000" to talk about an idealized future version]
a defense of low expectations, since nothing is more disappointing than betraying expectations you've set, and OSAF's certainly done plenty of that over the last 3 years now...
Brendan
On 11/28/05, Mimi Yin <[EMAIL PROTECTED]> wrote: And here was my reply...
Hi Alec, thanks so much for the detailed feedback, see more below...
On Nov 18, 2005, at 10:42 AM, Alec Flett wrote:
Hey Mimi, a few points of feedback... I went through the page/documents in the order they were on the page, trying to play the part of a user trying to learn what chandler is.. really trying to play naive..
1) on a very simple, interacting-with-the-page level, I noticed:
a) I had to choose between PPT and PDF - why can't these just be web pages? I don't see anything unique in these files that couldn't be represented with HTML... maybe this isn't true for everyone, but honestly whenever I see PDF I think to myself "ugh, then I have to wait for the PDF viewer to start, and wait for the file to download, yuck"
b) from a community perspecitve, PPT and all other microsoft formats are simply going to give us some bad mojo. The open source community doesn't just hate closed formats, they actually look down on them. Even if we don't just offer HTML versions of these pages, I think we're better off with JUST pdf, rather than PPT and PDF.
Think of it like the classic old lessons they tell businessmen going to china/etc - "Make sure not to show them the bottoms of your feet - its offensive" - same goes for Microsoft documents and open source communities :)
(And to be honest, PDF in place of a web page gets a similar reaction, just not nearly as strong)
Yup, absolutely, I'm just being lazy right now because I'm expecting to make a lot of changes after I get feedback from people. Once I have a more stable draft, I'll figure out a way to make them HTML.
2) I liked the "target user" PDF - it grabbed me, got me interested - it was compelling.
:o)
Yeah, the virtuality deck is really tough. Maybe I should split it up, just have a very simple glossary almost of what different elements are first and then take the more high-level conceptual stuff and shuttle it into a separate more advanced: Information Architecture slide deck?
I think also, the elevator pitch that's missing from the top of the page actually will say what Chandler is, as in it's a PIM, but you're right I should reiterate that here.
3) I had some big problems with the virtuality document. I got very confused in the first few pages, then was really wowed by the next few pages. Then I took a step back and realized I hadn't really learned what chandler actually IS. I think the last screenshot on the 11th slide was the only place I started to "get it" - but frankly I was lost long before I got there.
a) chandler has a history of over-promising and under-delivering. Every person I've ever met who has heard of us has been disappointed with where we are relative to the original vision. They ask me "what happened to the peer-to-peer stuff?" "why does it suck so much as an e-mail client?" - All things that OSAF made great proclamations about and then backed off from. This document describes where chandler will be in probably 2007 or 2008 - not because we don't want to be there, but because we have a LOT of code to write before we get to what you're describing. I'm really concerned about what chandler is promising to be. Slide 5 is especially compelling for a new users... but concerns me, as a member of OSAF, because we're claiming to do everything that all of these apps do, and they EACH took a team larger than ours YEARS to develop... and we're not going to be there for a LONG time.
So I guess, my feeling on this is a little different. The things described in these slides are all for Version 1.0, we can have a separate conversation about whether that's actually feasible, but the party line right now, is that this is what we're shooting for.*** As for the issue of over-promising and under-delivering, I guess I see these slides and the research and designs they attempt to summary to be a 1st concrete deliverable towards realizing the "vision" of chandler. At the FLOSS open-source usability sprint I went to, we talked a lot about how usability people, testers, designers, HCI specialists...might be able to contribute in real ways to open source projects and how open source projects might come to value "things that are not code" as substantive contributions. I see your point that people will still be skeptical unless there's something working, but I think we should recognize that we have made progress from the days when Chandler was just going to be: a revolution in PIMs, but we weren't clear on what that actually meant and how that might be accomplished? I guess now we sort of know the answers to those two questions and that in itself is progress?
b) I don't like the 1st (4th?) person language - "We mean.." - I think framing in terms of chandler, not a specific group of people, is simply more professional. I started to ask myself, "who are they, that they "mean this" or "mean that"?
Good point.
c) I think the word "affordances" should be struck from all public documents. Its a very proprietary word in the design/UI world. I had actually never heard it until coming to OSAF though I understand now that there are certain environments where the word is well understood.. but the target user doesn't live in that environment :) (If we had the word "Python" anywhere in these documents, I'd have a similar opinion on that word :))
Hmmm, it's a generic product design word too. I'll think about a replacement. If you have any ideas let me know.
d) I think the first few slides are too abstract and too chandler-specific to be shown this early. I went from "ooh, manage all my information!" to "Attributes are Labels...." to "Attributes are typed into 6 categories" and "Chandler has 6 Kinds" What? is that even english? I think we've all gotten very used to using Kind as an almost-proper noun within the context of chandler, but even grammatically it's extremely awkward. Further, I think this breakdown of the building blocks of meta information is just too abstract. And specifically, "Attributes are Labels" might as well be "Labels are Attributes" or "Roads are Streets" or "Streets are Roads" - there's no added value here. And I didn't even know Kinds had subKinds until I saw it in your document :)
e) while I appreciate the "Kinds are Sets of Attributes" panel, I think the diagram is a huge leap and is very difficult to wrap your brain around - I don't even think its necessary when introducing chandler. Maybe down the road when people understand how items interact, but this diagram is really wacky.
Yeah I think all of this should be presented as: read this if you're into understanding Chandler's Information architecture, which will be the case for people who get this far into the documentation for 0.6 I think. Information architecture geeks basically. I'm also going to play with how I might introduce the "Kinds are Sets of Attributes" panel over several slides, which might make it more palatable.
I guess from a design perspective, these virtuality slides show how Chandler's "flexible" content model is different from everybody else's flexible content model, which usually consists simply of tagging. Maybe the feedback here is to explain first why someone should care about the virtuality in the first place? Which I guess is what you're trying to say below with the algebra examples.
f) when I finally got to the screenshot, I started to see what was going on, but it would have been nice to have seen this FIRST to at least understand what this magic abstraction looks like. .. but even the screenshot was very cluttered and I couldn't figure out what half of the icons were for. (And by the way, a bass clef for "Media"? very clever, but very esoteric :))
Maybe half of the problem with the Chandler Virtuality is that its really a "behind the scenes" look into how data relationships are managed - something to help people make that NEXT leap after they understand the basics that chandler keeps track of different kinds of data. You're explaining everything up front, without allowing people to wrap their heads around the basics.
When teaching algebra for the first time, the explanation goes something like:
x is an unknown variable. When you see things like "x + 5 = 10" you can figure out that x is really 5 - see, if it is 5, then the equation works out. You can also figure out x in other contexts, like "x * 2 = 20" or " x/4 = 3"
Later, you might explain how there can be other variables, and learn how to solve for x, etc.
But I feel like the virtuality presentation is more like saying:
x is an unknown variable, in fact any letter or set of letters is an unknown variable. So, given any arbitrary function f and n different variables, f(x[1..n]) = K, its possible to determine the variables indexed in x by finding the inverse of f, called f-1, in terms of K.
Basically, its too much all at once, making it too abstract, too hard to wrap your brain around if you've never seen all this before. I personally completely understand what each of your slides refers to.. but I don't think a new user, even a very smart knowledge worker, will.
Anyhow, I hope that helps - I know its quite a bit of feedback :)
Alec
Mimi Yin wrote: The "Chandler in a Nutshell" presentation I sent out a few weeks ago has had a celebrity makeover and is now officially in the "Looking for feedback" stage.
What are we trying to accomplish with this page? 1. To communicate Chandler's high level goals and design philosophy through a structural understanding of the design. 2. We want people to walk away from these presentations with an overall sense of how Chandler strives to be innovative in the PIM space and why people should care about it.
Who is our audience? The community of people who come to find out more about Chandler as a result of the 0.6 release. This group is going to be varied and impossible to pin down in an exact persona. However, we generally expect that people who manage to click down this far beyond the 0.6 landing page will have a higher tolerance for complexity and are specifically interested in understanding something beyond Chandler's elevator pitch.
What 's still missing? 1. A high-level paragraph explaining OSAF's mission statement with respect to Chandler, which we are still working on. 2. A slide deck on our open source collaborative design process. 3. A slide deck on GTD in Chandler.
Please feel free to post feedback to the list or to write comments at the bottom of the wiki page.
Specifically, we're looking for:
1. Grammar and typos :o) 2. Where are there leaps in logic that make the slides hard to understand? 3. Overall tone and approach
Thanks! Looking forward to your thoughts.
Mimi :o)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
|
