Wiki pages...

Thu Sep 11 01:23:29 UTC 2008

Nice work!  This is looking really good.

We are still missing the Design overview page under the design links.   
So this page for inline edit for instance, http://wiki.fluidproject.org/display/fluid/Inline+Edit

Don't know if you're looking that kind of detail at this point.  So if  
not, I apologize for jumping into the details :)

-Daphne

On Sep 10, 2008, at 4: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
>>>
>>>
>>>
>>
>>
>

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: <http://fluidproject.org/pipermail/fluid-work/attachments/20080910/a7cab318/attachment.html>