+1 This sounds like a great structure to meet our goals of easy
access and the distinction between the kinds of deliverables we are
offering.
-Daphne
On Jun 3, 2008, at 4:52 PM, Paul Zablosky wrote:
I agree. We have the "release manual" material, which tracks the
releases, and the "other user manual material" which is under
constant development. My own feeling is that we should set up a
single table of contents to reflect this. The (virtual) user manual
would comprise two sections, organized something like this:
Release Manual
Component descriptions
API descriptions
Component-related tutorials
Release notes
Downloading
etc
User Guide to Fluid
UX Toolkit
User Experience material
OSDPL material
VULab material
other exciting stuff
We're pretty close to this now. I'd like to have only one ToC, just
to give our readers a single starting place for their excursions
through our documentation. But I'm interested to hear other's
opinions on this.
Paul
Daphne Ogle wrote:
Reading this thread, I keep wondering what other avenues we have
for letting the community know about Fluid UX projects that might
be useful to them (Higher Ed personas, content management use
cases) yet is not part of the release. The release date doesn't
put a stake in the ground for this material as it does with
components, APIs and the such. It is continuously growing and
becoming more refined. So in that sense it doesn't really make
sense for it to be part of a release manual. On the other hand,
these things are a valuable deliverable for the communities. Do we
need a separate jumping off point (perhaps TOC) for UX Projects/
Toolkit and deliverables?
-Daphne
On Jun 2, 2008, at 4:37 PM, Paul Zablosky wrote:
This whole exercise of creating a virtual user manual has raised
all sorts of interesting questions. I'm delighted to see these
things being discussed as the ToC evolves. Is it a release manual
(our original objective), or a manual for people using any of the
resources of the Fluid project (something it may be morphing into)?
I'm inclined to let it develop a bit, but keep discussion going on
important issues, such as how we keep release-specific content
distinguished from release-independent stuff -- the issue
Anastasia addressed. We'll need a few guidelines to keep things
under control. I offer the following for discussion:
Content that is associated with the Fluid software releases should
be readily identifiable and easily found by the release
consumers. Right now we have it as the first sections of the
ToC. We should keep it this way until we come up with a more
logical setup.
Annotations should give the user a age without clicking on it. We
should always keep that in mind when composing or editing them.
Section annotations should help the users decide if the material
in the section is going to be generally of interest to them.
The ToC should not have any child pages. Pages with manual-only
content should be attached to a central "Manual" parent page, if
they have no other logical home.
The ToC has now grown to about 2 1/2 scrollable screens in size.
At some point it may become unwieldy. I have been toying with the
idea of have cloakable sections but I'm not sure this is a good
idea. It would mean the user having to click rather than scroll.
What this whole scheme needs is some user testing. Is it doing
its job of making the Fluid reference material more accessible to
consumers of the Fluid deliverables? How can we find out? We may
not be ready for that yet -- we may want to do a few more rounds
of refinemen hing to keep in mind.
Paul
Colin Clark wrote:
Allison,
On 2-Jun-08, at 5:55 PM, Allison Bloodworth wrote:
I think the main impetus for adding this section was that we
wanted to share out the results of the Content Management
Research as a way of reporting on the state of UX in the Fluid
communities (which I believe is one of the Fluid deliverables).
After adding this, I realized that the results of the UX
Walkthroughs are also something that we should probably share.
I'm not entirely sure the OSDPL working group belongs there, but
I added it at the last moment to publicize that effort and maybe
it should be deleted. I guess the question is, who is the
audience of the manual and would they find this information
helpful (or conversely does the manual become overwhelming for
most of our audience when it is included)?
The nice thing about not freezing our documentation in PDF format
is that we can take some time to work out this question and
change the table of contents whenever we decide. :)
Colin
---
Colin Clark
Technical Lead, Fluid Project
Adaptive Technology Resource Centre, University of Toronto
http://fluidproject.org
_______________________________________________
fluid-work mailing list
[email protected]
http://fluidproject.org/mailman/listinfo/fluid-work
Daphne Ogle
Senior Interaction Designer
University of California, Berkeley
Educational Technology Services
[EMAIL PROTECTED]
cell (510)847-0308
Daphne Ogle
Senior Interaction Designer
University of California, Berkeley
Educational Technology Services
[EMAIL PROTECTED]
cell (510)847-0308
_______________________________________________
fluid-work mailing list
[email protected]
http://fluidproject.org/mailman/listinfo/fluid-work
