Wiki pages...

[Jess Mitchell]

+1

J
~~~~~~~~~~~~~~~~~~~~~~
Jess Mitchell
Boston, MA, USA
Project Manager / Fluid Project
jess at jessmitchell.com
/ w / 617.326.7753  / c / 919.599.5378
jabber: jessmitchell at gmail.com
http://www.fluidproject.org
~~~~~~~~~~~~~~~~~~~~~~




On Sep 10, 2008, at 9:57 AM, erin yu 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
>>
>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20080910/7bcfb244/attachment.html>