Table of contents for Fluid user manual

[Daphne Ogle]

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 an idea of what's on the page  
> 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  
> refinement first -- but it's something 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 audience question--will they find this particular information  
>> helpful or overwhelming?--is exactly the right question, and one  
>> which I'm unsure of the answer to.
>>
>> 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
> fluid-work at fluidproject.org
> http://fluidproject.org/mailman/listinfo/fluid-work

Daphne Ogle
Senior Interaction Designer
University of California, Berkeley
Educational Technology Services
daphne at media.berkeley.edu
cell (510)847-0308



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20080603/1d829181/attachment.htm>