Wiki pages...

Justin justin.obara at utoronto.ca
Thu Sep 11 12:46:26 UTC 2008


Hello,

The page is coming together nicely. I agree that we probably don't  
need the limitations information on this page.

I'm interested to see how it will look when actual information is  
added. My only fear is that the description section will become large  
and hide the other information below the fold. I suppose we won't  
really know this till an actual page is put together though.

- Justin
On 10-Sep-08, 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.
>
>
> 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
>> University of Toronto - ATRC
>> Tel: (416) 946-3002
>>
>>
>> On Wed, Sep 10, 2008 at 9:57 AM, erin yu <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
>>>>> cell (510)847-0308
>>>>>
>>>>>
>>>>>
>>>>
>>>> Allison Bloodworth
>>>> Senior User Interaction Designer
>>>> Educational Technology Services
>>>> University of California, Berkeley
>>>> (415) 377-8243
>>>> abloodworth at berkeley.edu
>>>>
>>>>
>>>>
>>>>
>>>
>>> Daphne Ogle
>>> Senior Interaction Designer
>>> University of California, Berkeley
>>> Educational Technology Services
>>> daphne at media.berkeley.edu
>>> cell (510)847-0308
>>>
>>>
>>>
>>
>>
>
> _______________________________________________
> fluid-work mailing list
> fluid-work at fluidproject.org
> http://fluidproject.org/mailman/listinfo/fluid-work

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20080911/92fc3e67/attachment.html>


More information about the fluid-work mailing list