Inline Edit - caret position when entering edit mode

Daphne Ogle daphne at
Wed Aug 27 00:06:44 UTC 2008

I like it!  Let's do it!

Inline edit is that weird bird where we have a family of functionality  
so perhaps it actually gets a family of status bars:  simple text,   
date picker, dropdown, editible link, etc.  Each of those could then  
have a status bar for the features within it.

Thinking aloud a bit about how we might take advantage of jira and  
confluence for this.   If we put all story cards in jira (we haven't  
been putting in story cards that aren't on the radar to be scheduled  
work) and they are at the feature level of granularity, we could  
easily see what is and isn't complete.


On Aug 26, 2008, at 3:22 PM, Jess Mitchell wrote:

> Hey y'all,
> This is good stuff that Jonathan and I were just talking about  
> today.  We do need a way to communicate progress.  And I really like  
> Justin's example below.  It gets at a few things: 1. completion or  
> near completion 2. complexity or phases of work (which nicely maps  
> to scope and iteration planning, incidentally), and 3. it's simple.
> Let's do simple for now!  To that end I'm wondering if we are at a  
> point (now that our JIRAs match our design process) where we can do  
> the below simply and easily on the wiki.
> For example, I had a look at the inline edit storycards:
> In-line Edit
> | 
> ------------------------| 
> ------------------| 
> ------------------|-------------------|------------------------|
> Simple i.e. 	   Undo            i.e. date picker     redo        	 
> dropdown           Complete
> Justin, I know you weren't advocating for this particular solution  
> to a progress bar, but it has all the features that I was hoping for  
> weeks ago.
> Let's do it -- low cost.
> Best,
> Jess
> On Aug 26, 2008, at 4:10 PM, Justin wrote:
>> Thank you for the explanation Daphne.
>> As for the progress and state of development stuff. I have been  
>> using the story boards, story cards and etc. as a means to write  
>> test plans which I would hope would reflect what end goal. As an  
>> example of this, for the inline edit test plan the undo tests have  
>> been a part of it for a while, but marked as not yet implemented.
>> I don't think it is necessary to file bugs for features which have  
>> not yet been implemented, so it would seem useful to have some way  
>> to monitor which features have been added to a component. I believe  
>> Jess was thinking about this, with the idea of a progress bar.  
>> Keeping with that thought, the progress bar could have a scale of  
>> features as opposed to a percentage.
>> something like :
>> | 
>> ------------------------| 
>> ------------------|------------------|-------------------|
>> Feature 1       Feature 2        Feature 3        Feature  
>> 4           Complete
>> Where Feature # would be the name of some feature. This would give  
>> an idea of what was complete and what was still on the horizon. An  
>> issue with this maybe that the order listed may differ from the  
>> order features are actually completed, and thus may not give an  
>> accurate representation of what will be implemented next.
>> It could also just be listed as a set of tasks in a task list on  
>> the wiki. Then the tasks could be ticked off as they are completed.
>> I'm not too sure what the best approach would be, just throwing out  
>> some thoughts.
>> thanks
>>  Justin
>> On 26-Aug-08, at 3:22 PM, Daphne Ogle wrote:
>>> Hi Justin,
>>> That is quite confusing.  Sorry about that.
>>> The first example is how we'd like to move forward.  The other 2  
>>> were how it was supposed to work until we got undo working.   
>>> Highlighting (selecting) the entire text when the user clicks in  
>>> the box has a higher chance of the user accidentally making an  
>>> edit or deleting the existing text so we didn't want that to  
>>> happen until undo was implemented.  The newest storyboard includes  
>>> undo and thus highlighted text (even though it's not implemented)  
>>> because Eli is building a prototype for user testing based on  
>>> it.   It seems to be a difference between the state of  
>>> implementation and our end goal.  Thoughts on how we can better  
>>> communicate this?  Do we need a QA space for the release that  
>>> specifies where development is as opposed to the end goal?
>>> -Daphne
>>> On Aug 26, 2008, at 6:11 AM, Justin wrote:
>>>> In the inline-edit simple text story boards (
>>>> ) there are several examples given.
>>>> The first case states that when the field enters into edit mode,  
>>>> all
>>>> of the text should be selected.
>>>> The second case states that the caret should be at the end of the  
>>>> text.
>>>> The third case doesn't mention where the caret or selection  
>>>> should be
>>>> but shows the caret in the middle of the text. This seems to imply
>>>> that the caret should be placed where the user clicks on the  
>>>> field to
>>>> put it into edit mode.
>>>> I'm not sure which one of these is/should be correct. Are these
>>>> supposed to indicate three different ways that the inline edit  
>>>> field
>>>> will behave based on context? If that is the case, would it be
>>>> confusing for the user, as all three could theoretically be on the
>>>> same page?
>>>> - Justin
>>>> _______________________________________________
>>>> fluid-work mailing list
>>>> fluid-work at
>>> Daphne Ogle
>>> Senior Interaction Designer
>>> University of California, Berkeley
>>> Educational Technology Services
>>> daphne at
>>> cell (510)847-0308
>> _______________________________________________
>> fluid-work mailing list
>> fluid-work at

Daphne Ogle
Senior Interaction Designer
University of California, Berkeley
Educational Technology Services
daphne at
cell (510)847-0308

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

More information about the fluid-work mailing list