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
|
