Wiki pages...

Jonathan Hung jonathan.hung at utoronto.ca
Wed Sep 10 20:12:45 UTC 2008


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


More information about the fluid-work mailing list