Inline Edit - caret position when entering edit mode

Justin justin.obara at utoronto.ca
Tue Aug 26 20:10:40 UTC 2008


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 (http://wiki.fluidproject.org/display/fluid/Inline+Edit+Storyboard+-+Allow+user+to+edit+simple+text
>> ) 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 fluidproject.org
>> http://fluidproject.org/mailman/listinfo/fluid-work
>
> 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/20080826/cce88732/attachment.html>


More information about the fluid-work mailing list