Inline Edit - caret position when entering edit mode

Jess Mitchell jess at jessmitchell.com
Tue Aug 26 22:22:16 UTC 2008


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 (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
>>
>>
>>
>
> _______________________________________________
> fluid-work mailing list
> fluid-work at fluidproject.org
> http://fluidproject.org/mailman/listinfo/fluid-work

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


More information about the fluid-work mailing list