Component Progress Indicators

Mara Hancock mara at
Fri Sep 5 17:22:49 UTC 2008

If there are dependencies, then visually representing those is  
probably important.

On Sep 5, 2008, at 9:26 AM, Jess Mitchell wrote:

> John,
> We were thinking of families of components, not parents and peers.   
> But I think that will get to the same end and you're right,  
> reorderer is the parent.
> We have two component families right now:  reorderer and inline  
> edit.  We will certainly take on making their presentation more  
> straightforward.  Many apologies for the confusion!
> Best,
> Jess
> ~~~~~~~~~~~~~~~~~~~~~~
> Jess Mitchell
> Project Manager / Fluid Project
> jess at
> / w / 617.326.7753  / c / 919.599.5378
> jabber: jessmitchell at
> ~~~~~~~~~~~~~~~~~~~~~~
> On Sep 5, 2008, at 11:12 AM, John Norman wrote:
>> I got an offlist comment about reorderer which made me revisit the  
>> site and I got confused. Nico helped me out. The issue is that  
>> components are presented as peers, but (as Nico presented it) the  
>> reordered is like a parent (or container component) for two other  
>> components - lightbox and layout customiser. So if we are looking  
>> at using layout customiser, we are necessarily looking at using  
>> Reorderer.
>> I had not properly understood this and would suggest that the site  
>> presentation of all components as peers does not help discovery of  
>> this relationship/dependency. Reusing the lightbox image for the  
>> reorderer component at 
>>  does not help. A parent component that does not have a UI might be  
>> better represented by a snippet of code image.
>> Just a suggestion.
>> John
>> On 5 Sep 2008, at 14:50, Jess Mitchell wrote:
>>> John,
>>> Thanks so much for your thoughtful email!  This is great feedback  
>>> and we're excited to make this new tool better.
>>> You have indeed mentioned some of the points that we're working  
>>> on, namely: a template for the component pages that will have  
>>> anchored sections that clearly match up with the elements in the  
>>> indicator and the progress indicator situated within that page --  
>>> that should help with some understandability.  We'll also have the  
>>> progress indicators living on that page eventually.
>>> But you also bring up some really good points that we need to  
>>> address:  namely "completeness" and what it means, explaining  
>>> "families" of components like reorderer, and how to represent  
>>> features of the components we haven't even thought of adding, but  
>>> will be added to a "complete" component?  So, we've got some work  
>>> to do on this.
>>> We look forward to working with y'all on implementation!  And have  
>>> Nico get in touch with us about implementation of the Layout  
>>> Customizer.
>>> Best,
>>> Jess
>>> ~~~~~~~~~~~~~~~~~~~~~~
>>> Jess Mitchell
>>> Project Manager / Fluid Project
>>> jess at
>>> / w / 617.326.7753  / c / 919.599.5378
>>> jabber: jessmitchell at
>>> ~~~~~~~~~~~~~~~~~~~~~~
>>> On Sep 5, 2008, at 4:41 AM, John Norman wrote:
>>>> First I want to say this is a great resource, BUT...
>>>> I just had occasion to actually want to *use* a progress indicator.
>>>> This is good news, Nico came to me saying he wanted to put the  
>>>> Fluid
>>>> Reorderer into the Sakai UX work. So first I went to look at his  
>>>> demo
>>>> of it working with the Nathan's new skin and Sakai gadgets (I was
>>>> worried by the clunky drag and drop I had seen when I last looked).
>>>> The experience was good, very familiar and ext-like so I agreed it
>>>> might be ready to use. But then I thought, so how finished is it  
>>>> and
>>>> what is the likelihood of a big change coming along and disrupting
>>>> the  UX project in some way by doing something unexpected or  
>>>> unwanted,
>>>> or it turning out to have poor performance so we had to pull it  
>>>> back
>>>> out until fixed. The progress chart seemed the obvious place to get
>>>> answers so I went and looked. I found myself with fewer answers  
>>>> than I
>>>> expected and thought I should share the experience.
>>>> 1. First problem: what component should I be looking at? There  
>>>> seemed
>>>> to be 2 possibilities Layout Customiser and Reorderer. Nico seemed
>>>> pretty confident that he had used the Layout Customiser so that is
>>>> what we looked at, but I noted that the page assumed you understood
>>>> what each component did - a very brief description for  
>>>> disambiguation
>>>> purposes in this case would have been useful.
>>>> 2. Next problem was; what does "complete" mean. Until the Flash
>>>> uploader incident, I would probably not have questioned this and
>>>> assumed that "complete" meant feature complete and fully tested for
>>>> heavy production load - i.e. 'production ready'. The Flash  
>>>> uploader is
>>>> "complete" but there is a massive risk associated with the Flash
>>>> Player 10 non-functionality that is not mentioned, potentially
>>>> allowing me to make a poor production decision, so perhaps  
>>>> 'complete'
>>>> does not mean 'production ready'. I looked for a definition of
>>>> "complete" but didn't readily find one.
>>>> 3. Next problem is the elements on the page (like "columns" or
>>>> "locked"). I wondered what they meant. There seemed to be a
>>>> correlation to the items listed below the colour bar, but all items
>>>> linked to a single specification page that did not easily correlate
>>>> with the names, i.e. even by reading the specification page I could
>>>> not tell the scope of specification that related to the name  
>>>> "columns"
>>>> and that was marked as complete.
>>>> 4. Finally, there was a white item marked "..." and a corresponding
>>>> item on the bottom of the list. I didn't know what to make of  
>>>> this. I
>>>> assumed it meant the spec scope was unfinished and there was an
>>>> indefinite amount of unknown work still to be done, so progress  
>>>> could
>>>> be 80% done or 5% done and there was no way to know when the  
>>>> component
>>>> might be finished.
>>>> So for this single example, the entry turned out to be almost  
>>>> totally
>>>> useless for *my* purpose, which was to decide if it was safe to
>>>> consider using the component in a production environment.
>>>> I wrote this down to try to be helpful, not to criticise. I  
>>>> appreciate
>>>> that it is work in progress and I would like to remind you of the  
>>>> good
>>>> news - we are thinking we might be ready to put the component  
>>>> into our
>>>> production code and built it into the UX work. I just thought  
>>>> that I
>>>> had an example of the intended use of the page and you should know
>>>> that in its current form it turns out to be less useful than it
>>>> appeared on the surface when I looked at it for the conference  
>>>> call.
>>>> Best, John
>>>> On 3 Sep 2008, at 21:00, Jess Mitchell wrote:
>>>>> I think these look awesome.  And I think it's meaningful that I've
>>>>> been pointing people to this page all day while having  
>>>>> conversations
>>>>> about components.
>>>>> Wonderful work y'all.
>>>>> Jess
>>>>> ~~~~~~~~~~~~~~~~~~~~~~
>>>>> Jess Mitchell
>>>>> Project Manager / Fluid Project
>>>>> jess at
>>>>> / w / 617.326.7753  / c / 919.599.5378
>>>>> jabber: jessmitchell at
>>>>> ~~~~~~~~~~~~~~~~~~~~~~
> _______________________________________________
> fluid-work mailing list
> fluid-work at

Mara Hancock
Educational Technology Services Interim Director
University of California, Berkeley
Educational Technology Services
9 Dwinelle Hall, #2535
Berkeley, CA 94720

Desk: 510-643-9923
Mobile: 510-407-0543

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the fluid-work mailing list