[Infusion-users] fluid infusion: dropdown inline edit & multiline inline edit

Christian Vuerings vueringschristian at gmail.com
Mon Nov 16 00:36:14 UTC 2009


Hi Colin,

Thanks for all your valuable answers, this really helps us in the  
further development of Sakai.

> There's been a lot of interest in this component, and we use it a  
> lot ourselves, so it's a big priority. The plan right now is to  
> contribute improvements back to the author of the selectbox plugin  
> to add better typeahead support, portal-friendliness, and  
> accessibility.

What do you think is the best thing to do to keep track off Fluid's  
progress on this component? Will there a post on one of the fluid  
mailing lists? Or is there a specific Jira we are able to watch?

> Yes, for sure. Inline Edit is really flexible about markup, so you  
> can provide just about anything inside the edit mode container. Just  
> stick a textarea in there, and you're pretty much ready to go. If  
> you want to do this programmatically, you can supply an  
> "editModeRenderer" function in your options to Inline Edit.


I will test these out first thing tomorrow.

> I'm interested to hear more about what your users are saying. The  
> design motivation for Inline Edit was to blur the modal distinction  
> between editing and viewing content. The point here is that it  
> should be easy to see content on the page, and then selectively edit  
> individual pieces of content.
>
> For keyboard users, this becomes important for helping to avoid  
> errors. There's no risk that they accidentally edit data while  
> they're navigating through a page.


Our users were not used to the fact that they had to press the enter  
key before they could insert some data (when you are used to filling  
in regular html forms). From your response I can definitely see why  
Fluid is doing it this way. I'm sure this topic and whether we'll use  
your suggestion to use the focus event that calls the edit method,  
will be discussed in the Sakai community.

Thanks again for your replies,
Christian


On 13 Nov 2009, at 20:52, Colin Clark wrote:

> Hey Christian,
>
> Great questions! Responses inline...
>
> On 5-Nov-09, at 4:51 AM, Christian Vuerings wrote:
>
>> 1) What is the plan for the "Dropdown Inline Edit" component, when  
>> do you think it is going from the "Sneak peek" status to the  
>> "Preview" status?
>
> The biggest reason we haven't already promoted Dropdown Inline Edit  
> to production status is that we're not 100% satisfied with the  
> jQuery selectbox plugin we use for rendering the dropdown. You've  
> probably seen the thread on this list about it.
>
> There's been a lot of interest in this component, and we use it a  
> lot ourselves, so it's a big priority. The plan right now is to  
> contribute improvements back to the author of the selectbox plugin  
> to add better typeahead support, portal-friendliness, and  
> accessibility.
>
> I'm not certain about timelines yet, but rest assured it's high on  
> our list of priorities.
>
>> 2) Is it possible to have a multiline inline edit, without the  
>> "Rich Text" functionality? (For now we use our own script to make  
>> the multiline edit work (without richtext) )
>
> Yes, for sure. Inline Edit is really flexible about markup, so you  
> can provide just about anything inside the edit mode container. Just  
> stick a textarea in there, and you're pretty much ready to go. If  
> you want to do this programmatically, you can supply an  
> "editModeRenderer" function in your options to Inline Edit.
>
> http://wiki.fluidproject.org/display/fluid/Inline+Edit+API#InlineEditAPI-Options
>
> Off the top of my head, I'm not sure if we have any examples of this  
> in action, but it should be pretty straightforward.
>
> Antranig may be able to chime in with details about how our more  
> sophisticated editModeRenderer and blurBinder functions work if you  
> want to create a more refined customized behaviour or integrate  
> other types of rich text editors.
>
>> 3) Some users where complaining about the fact that when we use the  
>> "Simple Text Inline Edit" component and they use the tab key for  
>> navigating to each editable item. They first need to press the  
>> enter key before they can edit the content. Is there any reason why  
>> you did it this way and are we able to change this behaviour? e.g.  
>> If you start typing and the editable field has the focus, you are  
>> can enter data.
>
> I'm interested to hear more about what your users are saying. The  
> design motivation for Inline Edit was to blur the modal distinction  
> between editing and viewing content. The point here is that it  
> should be easy to see content on the page, and then selectively edit  
> individual pieces of content.
>
> For keyboard users, this becomes important for helping to avoid  
> errors. There's no risk that they accidentally edit data while  
> they're navigating through a page.
>
> That said, the behaviour is certainly customizable. If you want an  
> Inline Editor to automatically switch into edit mode when it is  
> focused, you should be able to just a bind a focus event that calls  
> the edit() method on Inline Edit.
>
> I hope this helps,
>
> Colin
>
> ---
> Colin Clark
> Technical Lead, Fluid Project
> http://fluidproject.org
>




More information about the Infusion-users mailing list