Wiki pages...

Gary Thompson gary at unicon.net
Fri Sep 12 22:49:32 UTC 2008


Here's my latest take on the component landing page:
http://wiki.fluidproject.org/display/fluid/Layout+Customizer

It doesn't yet address the component family.

Gary



Jess Mitchell wrote:
> Great stuff y'all -- one comment inline below:
> ~~~~~~~~~~~~~~~~~~~~~~
> Jess Mitchell
> Boston, MA, USA
> Project Manager / Fluid Project
> jess at jessmitchell.com <mailto:jess at jessmitchell.com>
> / w / 617.326.7753  / c / 919.599.5378
> jabber: jessmitchell at gmail.com <mailto:jessmitchell at gmail.com>
> http://www.fluidproject.org
> ~~~~~~~~~~~~~~~~~~~~~~
>
>
>
>
> On Sep 10, 2008, at 7:02 PM, erin yu wrote:
>
>>
>> I had a discussion with Gary then with Jonathan today, and updated 
>> the landing page accordingly.
>> http://wiki.fluidproject.org/display/fluid/Component+at+a+glance
>>
>> Here are the suggested improvements:
>>
>>
>> 1. naming the page the component name itself, rather than 'Component 
>> at a glance'. i.e. calling the Uploader landing page "Uploader" 
>> rather than "Uploader at a glance"
>>
>> 2. moving the features section up into the description box at the 
>> top. The features that correspond to the storycards (in the progress 
>> indicator) would be listed and explained here.
>>
>> 3. removing the Limitations section as Jonathan mentioned in his 
>> email below.
>>
>> 4. Gary brought up a good point about the usefulness of the Progress 
>> Indicator once the component has been developed and is 'stable'. Do 
>> we still need the progress indicator then? Based on his experience 
>> integrating the layout customizer, a step-by-step instructions on 
>> 'how to integrate this component' would be much more useful. We 
>> talked about replacing the progress indicator section with this 
>> how-to section once the component is fully baked.
>
> My sense is we will continue to iterate on components even after 
> they've achieved stability.  And my sense is also the progress 
> indicator then serves the purpose of conveying that stability and also 
> providing a quick link to the individual story card "features" that 
> the component incorporates.  So, it serves as a quick articulation of 
> what the component can do without creating a longer narrative about 
> features.  So, my vote would be to keep it.
>
> J
>
>>
>>
>> With these changes, the landing page looking even more concise. :)
>>
>> re: Daphne's question: yes, the integration-related pages are linked 
>> from this landing page (in the grey box on the right). 
>>
>>
>> On 10-Sep-08, at 4:12 PM, Jonathan Hung wrote:
>>
>>> After talking with Erin, we're feeling that the "Limitations" 
>>> section isn't really needed.
>>>
>>> Initially this section was to provide a space where technical 
>>> limitations can be conveyed (an example is the Reorderer). However 
>>> it seems a bit too low-level to be on a "at a glance" info page.
>>>
>>> Also, a reader of the page should get a pretty good idea of what the 
>>> component can and can't do by the description and the listing of 
>>> features. So it seems a bit redundant in that way.
>>>
>>> What do you all think? Axe Limitations or should we keep it for a 
>>> purpose (and if so, what is that purpose)?
>>>
>>>
>>>
>>> ---
>>> Jonathan Hung / jonathan.hung at utoronto.ca 
>>> <mailto:jonathan.hung at utoronto.ca>
>>> University of Toronto - ATRC
>>> Tel: (416) 946-3002
>>>
>>>
>>> On Wed, Sep 10, 2008 at 9:57 AM, erin yu <erin.yu at utoronto.ca 
>>> <mailto:erin.yu at utoronto.ca>> wrote:
>>>
>>>     I think this is an excellent idea for the component design
>>>     overview page.
>>>
>>>     The landing page, in my opinion, should be concise and have
>>>     quick links to design as well as integration/dev resources. In
>>>     summary, I would suggest having these two overview pages per
>>>     component:
>>>
>>>     *[parent]  Component at a glance*
>>>     - serves as the  landing page
>>>     - explains what the component is, what it looks like, what it
>>>     does, what its limitations are
>>>     - has quick links to the demo, integration-related pages, and
>>>     design overview (and other main design pages, TBD)
>>>                                 |
>>>     *[child]  Component design overview*
>>>     - answers the 3 design questions Daphne explained below
>>>     - explains the problem and solution using scenarios and persona
>>>     - has structured links to design resources
>>>
>>>     Erin
>>>
>>>
>>>     On 9-Sep-08, at 8:53 PM, Daphne Ogle wrote:
>>>
>>>>     Comment below...
>>>>
>>>>     -Daphne
>>>>
>>>>     On Sep 9, 2008, at 2:36 PM, Allison Bloodworth wrote:
>>>>
>>>>>     I like this a lot too. I think the use of "The Problem" and
>>>>>     "The Solution" makes things very clear (and just happens to
>>>>>     mirror our design pattern format! :)). I also like the concise
>>>>>     explanation of the solution via the scenario, though I'm not
>>>>>     sure that would map directly to our domain as I think we'll
>>>>>     have multiple scenarios. I see this as sort of the "marketing"
>>>>>      scenario which "sells" the solution to people coming to the
>>>>>     page (boy, I'm sold on parking angel!). It might make sense
>>>>>     for us to come up with sort of an overview scenario (maybe
>>>>>     focusing on what we think the most urgent use cases are) for
>>>>>     our components for the initial page.
>>>>     Right -- this could be our primary scenario(s) or sampling of
>>>>     them.  The Uploader is the first component we've identified
>>>>     primary scenarios for and I could definitely see showcasing a
>>>>     couple of them on the main page as an overview of what the
>>>>     component is meant to support.
>>>>
>>>>     The other thing I like is they include a snippet of who the
>>>>     user is.  So it also nicely includes what I was trying to
>>>>     capture on the inline edit pages -- 3 very important questions
>>>>     in design:  1) Who are we designing for (persona), 2) What do
>>>>     they need (primary scenario), and 3) How are we meeting those
>>>>     needs (wireframes in the storyboard).
>>>>>
>>>>>     Allison
>>>>>
>>>>>     On Sep 9, 2008, at 12:55 PM, Daphne Ogle wrote:
>>>>>
>>>>>>     Hi all,
>>>>>>
>>>>>>     I just ran across this page on the Cooper site and really
>>>>>>     like the structure and content.  It's a nice clear, quick
>>>>>>     snapshot about what this thing is.  Could we borrow some
>>>>>>     ideas for our component design pages?
>>>>>>
>>>>>>     http://www.cooper.com/insights/concept_projects/parking_angel.html
>>>>>>
>>>>>>     It includes the problem statement, the design goals
>>>>>>     (solution) and the primary scenario storyboard.  Just some
>>>>>>     food for thought...  We could link to all the other
>>>>>>     information that's currently on our pages as child pages.
>>>>>>
>>>>>>     Daphne Ogle
>>>>>>     Senior Interaction Designer
>>>>>>     University of California, Berkeley
>>>>>>     Educational Technology Services
>>>>>>     daphne at media.berkeley.edu <mailto:daphne at media.berkeley.edu>
>>>>>>     cell (510)847-0308
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>     Allison Bloodworth
>>>>>     Senior User Interaction Designer
>>>>>     Educational Technology Services
>>>>>     University of California, Berkeley
>>>>>     (415) 377-8243
>>>>>     abloodworth at berkeley.edu <mailto:abloodworth at berkeley.edu>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>     Daphne Ogle
>>>>     Senior Interaction Designer
>>>>     University of California, Berkeley
>>>>     Educational Technology Services
>>>>     daphne at media.berkeley.edu <mailto:daphne at media.berkeley.edu>
>>>>     cell (510)847-0308
>>>>
>>>>
>>>>
>>>
>>>
>>
>



More information about the fluid-work mailing list