Rails spinoffs - Jul 2005 - in place text edit

I''ve written a pretty nice Flickr style in place text edit JavaScript
control based on the Script.aculo.us library.

API is like this:

<span id="editme">Edit me!</span>

<script>
  new InPlaceEditor($(''editme''),
''url/to/action'');
</script>

Background changes to gray as mouse hovers over the text (like flickr)
and the <span> is replaced (well, actually hidden) by a <form> when
you click it by dynamically creating DOM objects. When you click "ok"
it sends back the content of the text field to the server in the body
of the post, displays "Saving..." and then takes whatever the server
returns and updates the <span> with it.

It''s witten using TDD and has unit tests written in a simple unit
testing framework that I borrowed from a mailing list archive
somewhere (can''t find it again!) and then modified a bit.

I''d like to submit this to Script.aculo.us so I get other people
looking at it and getting it to work for more browsers and so forth.
I''ll likely be using this for an upcoming project. How do I submit
patches to Script.aculo.us?

Cheers,
Jon

Cool :)

The best thing for the moment is probably setting up a demo page and  
have the source available there.

Thomas

Am 18.07.2005 um 17:58 schrieb Jon Tirsen:
> I''ve written a pretty nice Flickr style in place text edit
JavaScript
> control based on the Script.aculo.us library.
>
> API is like this:
>
> <span id="editme">Edit me!</span>
>
> <script>
>   new InPlaceEditor($(''editme''),
''url/to/action'');
> </script>
>
> Background changes to gray as mouse hovers over the text (like flickr)
> and the <span> is replaced (well, actually hidden) by a <form>
when
> you click it by dynamically creating DOM objects. When you click
"ok"
> it sends back the content of the text field to the server in the body
> of the post, displays "Saving..." and then takes whatever the
server
> returns and updates the <span> with it.
>
> It''s witten using TDD and has unit tests written in a simple unit
> testing framework that I borrowed from a mailing list archive
> somewhere (can''t find it again!) and then modified a bit.
>
> I''d like to submit this to Script.aculo.us so I get other people
> looking at it and getting it to work for more browsers and so forth.
> I''ll likely be using this for an upcoming project. How do I submit
> patches to Script.aculo.us?
>
> Cheers,
> Jon
> _______________________________________________
> Rails-spinoffs mailing list
> Rails-spinoffs@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
>

Hmm... So I can''t just submit a patch somewhere? I don''t have
any good
hosting possibilities at the moment.


On 7/18/05, Thomas Fuchs <thomas@fesch.at> wrote:
> Cool :)
> 
> The best thing for the moment is probably setting up a demo page and
> have the source available there.
> 
> Thomas
> 
> Am 18.07.2005 um 17:58 schrieb Jon Tirsen:
> 
> > I''ve written a pretty nice Flickr style in place text edit
JavaScript
> > control based on the Script.aculo.us library.
> >
> > API is like this:
> >
> > <span id="editme">Edit me!</span>
> >
> > <script>
> >   new InPlaceEditor($(''editme''),
''url/to/action'');
> > </script>
> >
> > Background changes to gray as mouse hovers over the text (like flickr)
> > and the <span> is replaced (well, actually hidden) by a
<form> when
> > you click it by dynamically creating DOM objects. When you click
"ok"
> > it sends back the content of the text field to the server in the body
> > of the post, displays "Saving..." and then takes whatever
the server
> > returns and updates the <span> with it.
> >
> > It''s witten using TDD and has unit tests written in a simple
unit
> > testing framework that I borrowed from a mailing list archive
> > somewhere (can''t find it again!) and then modified a bit.
> >
> > I''d like to submit this to Script.aculo.us so I get other
people
> > looking at it and getting it to work for more browsers and so forth.
> > I''ll likely be using this for an upcoming project. How do I
submit
> > patches to Script.aculo.us?
> >
> > Cheers,
> > Jon
> > _______________________________________________
> > Rails-spinoffs mailing list
> > Rails-spinoffs@lists.rubyonrails.org
> > http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
> >
> 
>

Sure you can, just mail it to me :)

Thomas

Am 20.07.2005 um 16:34 schrieb Jon Tirsen:
> Hmm... So I can''t just submit a patch somewhere? I don''t
have any good
> hosting possibilities at the moment.
>
>
> On 7/18/05, Thomas Fuchs <thomas@fesch.at> wrote:
>
>> Cool :)
>>
>> The best thing for the moment is probably setting up a demo page and
>> have the source available there.
>>
>> Thomas
>>
>> Am 18.07.2005 um 17:58 schrieb Jon Tirsen:
>>
>>
>>> I''ve written a pretty nice Flickr style in place text edit
>>> JavaScript
>>> control based on the Script.aculo.us library.
>>>
>>> API is like this:
>>>
>>> <span id="editme">Edit me!</span>
>>>
>>> <script>
>>>   new InPlaceEditor($(''editme''),
''url/to/action'');
>>> </script>
>>>
>>> Background changes to gray as mouse hovers over the text (like  
>>> flickr)
>>> and the <span> is replaced (well, actually hidden) by a
<form> when
>>> you click it by dynamically creating DOM objects. When you click  
>>> "ok"
>>> it sends back the content of the text field to the server in the  
>>> body
>>> of the post, displays "Saving..." and then takes whatever
the server
>>> returns and updates the <span> with it.
>>>
>>> It''s witten using TDD and has unit tests written in a
simple unit
>>> testing framework that I borrowed from a mailing list archive
>>> somewhere (can''t find it again!) and then modified a bit.
>>>
>>> I''d like to submit this to Script.aculo.us so I get other
people
>>> looking at it and getting it to work for more browsers and so
forth.
>>> I''ll likely be using this for an upcoming project. How do
I submit
>>> patches to Script.aculo.us?
>>>
>>> Cheers,
>>> Jon
>>> _______________________________________________
>>> Rails-spinoffs mailing list
>>> Rails-spinoffs@lists.rubyonrails.org
>>> http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
>>>
>>>
>>
>>
>

Hehe, ok. I just noticed the testing framework in
scriptaculous/test/unittest.js. Very nice. I''ll port my unit tests to
that framework instead. Once that''s done I''ll submit a patch.

Questions:
Should this live inside controls.js? 
Should I name it Ajax.InPlaceEditor to comply with Ajax.AutoCompleter?

Cheers,
Jon 

On 7/20/05, Thomas Fuchs <thomas@fesch.at> wrote:
> Sure you can, just mail it to me :)
> 
> Thomas
> 
> Am 20.07.2005 um 16:34 schrieb Jon Tirsen:
> 
> > Hmm... So I can''t just submit a patch somewhere? I
don''t have any good
> > hosting possibilities at the moment.
> >
> >
> > On 7/18/05, Thomas Fuchs <thomas@fesch.at> wrote:
> >
> >> Cool :)
> >>
> >> The best thing for the moment is probably setting up a demo page
and
> >> have the source available there.
> >>
> >> Thomas
> >>
> >> Am 18.07.2005 um 17:58 schrieb Jon Tirsen:
> >>
> >>
> >>> I''ve written a pretty nice Flickr style in place text
edit
> >>> JavaScript
> >>> control based on the Script.aculo.us library.
> >>>
> >>> API is like this:
> >>>
> >>> <span id="editme">Edit me!</span>
> >>>
> >>> <script>
> >>>   new InPlaceEditor($(''editme''),
''url/to/action'');
> >>> </script>
> >>>
> >>> Background changes to gray as mouse hovers over the text (like
> >>> flickr)
> >>> and the <span> is replaced (well, actually hidden) by a
<form> when
> >>> you click it by dynamically creating DOM objects. When you
click
> >>> "ok"
> >>> it sends back the content of the text field to the server in
the
> >>> body
> >>> of the post, displays "Saving..." and then takes
whatever the server
> >>> returns and updates the <span> with it.
> >>>
> >>> It''s witten using TDD and has unit tests written in a
simple unit
> >>> testing framework that I borrowed from a mailing list archive
> >>> somewhere (can''t find it again!) and then modified a
bit.
> >>>
> >>> I''d like to submit this to Script.aculo.us so I get
other people
> >>> looking at it and getting it to work for more browsers and so
forth.
> >>> I''ll likely be using this for an upcoming project.
How do I submit
> >>> patches to Script.aculo.us?
> >>>
> >>> Cheers,
> >>> Jon
> >>> _______________________________________________
> >>> Rails-spinoffs mailing list
> >>> Rails-spinoffs@lists.rubyonrails.org
> >>> http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
> >>>
> >>>
> >>
> >>
> >
> 
> _______________________________________________
> Rails-spinoffs mailing list
> Rails-spinoffs@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
>

> Summing up, I''m getting the following options for the helper:
> :cancel_text
> :cancel_class
> :ok_text
> :ok_class
> :form_id
> :form_class
> :input_class
> :hover_class
> :saving_text
> :saving_class
> :saving_html
> :saving_callback (javascript snippet that simply overrides the
> existing behavior)
Forgot one:
:with
A JavaScript expression specifying the parameters for the
XMLHttpRequest. This defaults to ''field_id=value''.
''value'' can be used
to refer to the current value in the input box.

Another idea: maybe we should support an :indicator parameter like in
the existing auto complete functionality? It''s an element that will
get shown to indicate server communication and hidden when complete.
If this parameter is present then that overrides the existing
behavior. I still think we should support the "Saving..." behavior as
it''s very easy to use. Thoughts?

Also, we should write a helper method for the controller that defines
an action which is used to update the model:
editable_property_action_for :model, :property

This would generate an action equivalent to:
def set_model_property
  o = Model.find(params[:id])
  o.property = params[: property]
  o.save
  render :inline => o.property
end

What about error handling? What if the o.save fails with validation errors?

Please find some ideas on what the InPlaceEditor should support below.
Comments and ideas are much appreciated!
> Rails helper: Sure. Add a method to the JavaScript helper. It would
> be good to extend the inplaceeditor code to allow for setting
> addtional parameters for the AJAX call (pass-through-options) and to
> use (predefined) CSS classes for the mouseover and for the styling of
> the input, the cancel link (text should be changable!) and the button.
Agreed.
Regarding CSS class for hover: I was thinking by default that it
changes the background. If you specify a CSS class for hovering then
it uses that instead of changing the background. That way the hover
effect would always work without requiring you to do anything with
CSS. (Although CSS is obviously the right way to do this.)
I also think we should allow a CSS class or id for the form element as
it gets generated. It can get tricky with for example absolute
positioning if you can''t have anything to move the form with CSS.
(I''ve experimented with trying to clear out the innerHTML element to
be edited and then putting the form in there instead, but that gets
even more confusing. And I don''t think you''re allowed to have
a <form>
inside an <h1> in XHTML...?)
We should also have some kind of hooks to allow for other ways of
displaying the "save in progress" feedback.

Summing up, I''m getting the following options for the helper:
:cancel_text
:cancel_class
:ok_text
:ok_class
:form_id
:form_class
:input_class
:hover_class
:saving_text
:saving_class
:saving_html
:saving_callback (javascript snippet that simply overrides the
existing behavior)

Hope you don''t mind, but I''ll CC the mailing list to see if
there''s
anything I''m missing. Hello, mailing list! What do you all
want/don''t
want from the list above?

I''ve tried the new in-place-editor, it''s really nice.

If I gather correctly, the element id will be passed along in the  
next version? This is definately a requirement imho.

Also, will there be an option to use this on whole paragraphs? Using  
a textarea, or even a contenteditable approach?

I think there should be a way to assign the strings used for buttons,  
messages etc. You should be able to translate these for example.

Thinking along the lines of an :indicator parameter, maybe the form  
elements can be taken from a hidden div, so you are free to create  
your own form that can be cloned to the inline editor from a  
createForm method. I think it would be useful to have createForm  
instead (or alongside) createEditField.

Just some thoughts...

Hi all,

 

I''m new to the list so please forgive any lack of knowledge herein. 
I''m
using prototype and the controls/effect rather heavily.  I took a look
at your in-place editing and I had some questions about the direction,
as I''ve got similar stuff I''m working on.  

 

I realize the checked in version is probably just the stub of things in
progress, but a few early usage comments:

 - Clicking on the element to edit seems rather tricky, as there is no
indication to the user that this is how things work.  In my stuff I''m
binding other elements as controls to toggle editing on or off (with
Event.observe)

- Other people on the web have mentioned that often the app works to
fast.  By that they mean that users don''t know something has saved,
because it saved too quickly!  Following that advice, I usually add a
progress bar or spinning widget to show that saving is happening for at
least 0.5 seconds, even if the save to server happened instantly.  With
limited testing I''ve done with folks around this seems like enough to
make people realize that the item saved.  Right now I''d argue that
building in an extra delay while saving would be a good usability
decision, because users are so used to page reloads as confirmation.

- Do you have a clever plan about how to do in-place editing at the form
level?  The current way of addressing this seems to be to have the
server respond to an "I want to edit" request by returning HTML for
the
edit version of a form.  Similarly, to a "I''m saving" request
the server
responds with the HTML rendering of the info saved.  It''d be nice to
have javascript write all this stuff, just as your example writes the
form itself, but I haven''t come up with an elegant solution to this for
forms with multiple things yet (selects, inputs, checkboxes, radio,
etc).  I think is similar to what Fabien just asked.

 

Anyway, for my own needs, I''m extending and overriding to fit my own
preferences.  But I''m curious to see how other people are addressing
this type of dynamism.  Any thoughts about these ramblings?

 

Thanks for the great libs :-)

 

Rahul

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails-spinoffs/attachments/20050729/098a48d2/attachment.html

On 7/29/05, Rahul Bhargava <rahul@ntag.com> wrote:
>  
>  
> 
> Hi all, 
> 
>   
> 
> I''m new to the list so please forgive any lack of knowledge
herein.  I''m
> using prototype and the controls/effect rather heavily.  I took a look at
> your in-place editing and I had some questions about the direction, as
I''ve
> got similar stuff I''m working on.  
> 
>   
> 
> I realize the checked in version is probably just the stub of things in
> progress, but a few early usage comments: 
> 
>  - Clicking on the element to edit seems rather tricky, as there is no
> indication to the user that this is how things work.  In my stuff
I''m
> binding other elements as controls to toggle editing on or off (with
> Event.observe) 
This is an exact replica of how Flickr does this. If all Flickr''s
users are able to handle it then I then I think we''re fine. :-)

Seriously though, there''s a reason to why it works at Flickr:
There''s
feedback to the user with the change of the background as the mouse
pointer hovers over it. This gives a clue to the user that something''s
going on there and a natural response is to click it, this shows the
form which is pretty self-explanatory.

That said, I think we should support another element as a widget to
show the edit form. I''ll add that to my list of features.
> - Other people on the web have mentioned that often the app works to fast. 
> By that they mean that users don''t know something has saved,
because it
> saved too quickly!  Following that advice, I usually add a progress bar or
> spinning widget to show that saving is happening for at least 0.5 seconds,
> even if the save to server happened instantly.  With limited testing
I''ve
> done with folks around this seems like enough to make people realize that
> the item saved.  Right now I''d argue that building in an extra
delay while
> saving would be a good usability decision, because users are so used to
page
> reloads as confirmation. 
Did you really look at the correct InPlaceEditor? :-)

As the user clicks "OK" the widget changes the text to
"Saving..."
which gets replaced by the updated text when the server has finished
saving.

I will also add support for other means of giving feedback by allowing
for a custom JavaScript snippet which gets executed at the right time.
> - Do you have a clever plan about how to do in-place editing at the form
> level?  The current way of addressing this seems to be to have the server
> respond to an "I want to edit" request by returning HTML for the
edit
> version of a form.  Similarly, to a "I''m saving" request
the server responds
> with the HTML rendering of the info saved.  It''d be nice to have
javascript
> write all this stuff, just as your example writes the form itself, but I
> haven''t come up with an elegant solution to this for forms with
multiple
> things yet (selects, inputs, checkboxes, radio, etc).  I think is similar
to
> what Fabien just asked. 
Well, I have a couple of ideas on how to do this, but I''m not sure I
want this to go down that path. This is a widget for doing in place
editing of a single text field a la Flickr style. It''s *not* a generic
widget for editing anything (and I think there''s no way of ever doing
a generic widget for this).
> Anyway, for my own needs, I''m extending and overriding to fit my
own
> preferences.  But I''m curious to see how other people are
addressing this
> type of dynamism.  Any thoughts about these ramblings? 
If you come up with something good then please share it with the rest
of the list. This is why open source is so good, if you don''t like
something, just hack it! :-)

Cheers,
Jon

On 7/29/05, Fabien Franzen <fabien@loob.be> wrote:
> I''ve tried the new in-place-editor, it''s really nice.
Thank you very much!
> If I gather correctly, the element id will be passed along in the
> next version? This is definately a requirement imho.
Ayup, expect this Any Day Now (tm). :-)
> Also, will there be an option to use this on whole paragraphs? Using
> a textarea, or even a contenteditable approach?
Yes, I''m definitely considering textarea support to be built in. This
will probably just be a simple option.
> I think there should be a way to assign the strings used for buttons,
> messages etc. You should be able to translate these for example.
This will be supported Really Soon Now (tm). :-)
> Thinking along the lines of an :indicator parameter, maybe the form
> elements can be taken from a hidden div, so you are free to create
> your own form that can be cloned to the inline editor from a
> createForm method. I think it would be useful to have createForm
> instead (or alongside) createEditField.
Very good ideas!
I think we''ll do both!
I can quite easily add support for having another element be the
actual editor, all I''ll do is just change the onsubmit event hook on
the form (to do the Ajax call), show it, and then hide it again when
done.
Hmm... What about updating the text field with the current value?
Another id? A JavaScript snippet to do it?
I''ll also add a createForm or getForm method.

Great feedback! Keep it coming!

Cheers,
Jon

ah - great response.  thanks.

demos are here:
http://www.instituteofthefuture.org/js/inplace.php

my responses:

* regarding an edit control widget (second demo on that page)
point taken.  I''m not militant enough to make the usability guru 
argument that it must be underlined to suggest that it does something.  
adding an option to register another element as a controller would 
address my personal take on the interaction.  thanks.

* regarding what to show while saving (third demo on that page)
adding a hook for whileSaving or such would be great.  I did in fact 
use the widget :-P  my argument is that the "saving..." note appears 
and disappears so quickly that the user never sees it (because the 
server could save and return so fast), and thus gets no intermediate 
confirmation of any sort of communication that would have saved what 
they did.  I''m expressing support for adding in a totally fake delay to
give them that feeling that it''s doing something.  actually
I''m not
certain myself that this is a good idea, but it felt right for the tiny 
number of novice users I tried it with.  check out my hacked up 
example.

* regarding a generic form flip-to-edit-mode widget
thanks - I meant to ask what the goal of this in-place widget was, and 
you answered that.  it''s perfectly appropriate for the widget to handle
editing one text field, and that''s killer.  I''ll have to think
about
what editing the whole form means and how I''d want to do it before 
doing a demo of that.

clearly I made a bunch of changes to things, maybe some of those are 
useful ideas to other folks.  fun stuff :-)

peace,

rahul



On Jul 30, 2005, at 4:44 AM, Jon Tirsen wrote:
> On 7/29/05, Rahul Bhargava <rahul@ntag.com> wrote:
>>
>>
>>
>> Hi all,
>>
>>
>>
>> I''m new to the list so please forgive any lack of knowledge
herein.
>> I''m
>> using prototype and the controls/effect rather heavily.  I took a 
>> look at
>> your in-place editing and I had some questions about the direction, 
>> as I''ve
>> got similar stuff I''m working on.
>>
>>
>>
>> I realize the checked in version is probably just the stub of things 
>> in
>> progress, but a few early usage comments:
>>
>>  - Clicking on the element to edit seems rather tricky, as there is no
>> indication to the user that this is how things work.  In my stuff
I''m
>> binding other elements as controls to toggle editing on or off (with
>> Event.observe)
>
> This is an exact replica of how Flickr does this. If all Flickr''s
> users are able to handle it then I then I think we''re fine. :-)
>
> Seriously though, there''s a reason to why it works at Flickr:
There''s
> feedback to the user with the change of the background as the mouse
> pointer hovers over it. This gives a clue to the user that
something''s
> going on there and a natural response is to click it, this shows the
> form which is pretty self-explanatory.
>
> That said, I think we should support another element as a widget to
> show the edit form. I''ll add that to my list of features.
>
>> - Other people on the web have mentioned that often the app works to 
>> fast.
>> By that they mean that users don''t know something has saved,
because
>> it
>> saved too quickly!  Following that advice, I usually add a progress 
>> bar or
>> spinning widget to show that saving is happening for at least 0.5 
>> seconds,
>> even if the save to server happened instantly.  With limited testing 
>> I''ve
>> done with folks around this seems like enough to make people realize 
>> that
>> the item saved.  Right now I''d argue that building in an extra
delay
>> while
>> saving would be a good usability decision, because users are so used 
>> to page
>> reloads as confirmation.
>
> Did you really look at the correct InPlaceEditor? :-)
>
> As the user clicks "OK" the widget changes the text to
"Saving..."
> which gets replaced by the updated text when the server has finished
> saving.
>
> I will also add support for other means of giving feedback by allowing
> for a custom JavaScript snippet which gets executed at the right time.
>
>> - Do you have a clever plan about how to do in-place editing at the 
>> form
>> level?  The current way of addressing this seems to be to have the 
>> server
>> respond to an "I want to edit" request by returning HTML for
the edit
>> version of a form.  Similarly, to a "I''m saving"
request the server
>> responds
>> with the HTML rendering of the info saved.  It''d be nice to
have
>> javascript
>> write all this stuff, just as your example writes the form itself, 
>> but I
>> haven''t come up with an elegant solution to this for forms
with
>> multiple
>> things yet (selects, inputs, checkboxes, radio, etc).  I think is 
>> similar to
>> what Fabien just asked.
>
> Well, I have a couple of ideas on how to do this, but I''m not sure
I
> want this to go down that path. This is a widget for doing in place
> editing of a single text field a la Flickr style. It''s *not* a
generic
> widget for editing anything (and I think there''s no way of ever
doing
> a generic widget for this).
>
>> Anyway, for my own needs, I''m extending and overriding to fit
my own
>> preferences.  But I''m curious to see how other people are
addressing
>> this
>> type of dynamism.  Any thoughts about these ramblings?
>
> If you come up with something good then please share it with the rest
> of the list. This is why open source is so good, if you don''t like
> something, just hack it! :-)
>
> Cheers,
> Jon

On 7/30/05, Rahul Bhargava <rahul@ntag.com> wrote:
> ah - great response.  thanks.
> 
> demos are here:
> http://www.instituteofthefuture.org/js/inplace.php
> 
> my responses:
> 
> * regarding an edit control widget (second demo on that page)
> point taken.  I''m not militant enough to make the usability guru
> argument that it must be underlined to suggest that it does something.
> adding an option to register another element as a controller would
> address my personal take on the interaction.  thanks.
You make a good point and seeing the demo I notice it''s certainly
going to work. I''ll add support for this. May I use your code if I
give you proper acknowledgment?

I think the default will still be to behave exactly like the Flickr
control, but this will definitely be an option.
> * regarding what to show while saving (third demo on that page)
> adding a hook for whileSaving or such would be great.  I did in fact
> use the widget :-P  my argument is that the "saving..." note
appears
> and disappears so quickly that the user never sees it (because the
> server could save and return so fast), and thus gets no intermediate
> confirmation of any sort of communication that would have saved what
> they did.  I''m expressing support for adding in a totally fake
delay to
> give them that feeling that it''s doing something.  actually
I''m not
> certain myself that this is a good idea, but it felt right for the tiny
> number of novice users I tried it with.  check out my hacked up
> example.
Interesting... When you''re talking to an app running locally or on the
LAN then it''s certainly going to be very fast. An effect like Yellow
Fade Technique would give a better feedback as it by nature sticks
around for longer. When the server is on WAN though the latency is
going to make "Saving..." appear for a longer time.

I''m not sure I like the idea of artificially making your app slower. I
really like the fact that an AJAX app is ultra-fast! :-)

I''ll add support for some sort of onLoading and onComplete callback so
you can plug in anything you like. Delays, Yellow Fade Technique,
effects and so on. Horses for courses. :-)
> * regarding a generic form flip-to-edit-mode widget
> thanks - I meant to ask what the goal of this in-place widget was, and
> you answered that.  it''s perfectly appropriate for the widget to
handle
> editing one text field, and that''s killer.  I''ll have to
think about
> what editing the whole form means and how I''d want to do it before
> doing a demo of that.
I initially wrote the widget because I had a page with a *lot* of
in-place edit elements. Having a hidden form for each of these
elements made the page several times larger then it needed to be!
That''s why I wanted a very simple control that created the DOM on the
client side. So I suppose that''s the scope of the control.

A generic flip-to-edit-mode widget is also interesting, but I think it
would have to be a different control. I don''t think it''s good
to
over-generalize things to the point that the basic usage is hard and
the complex usage is still complex.

Open to suggestions of course. :-)
> clearly I made a bunch of changes to things, maybe some of those are
> useful ideas to other folks.  fun stuff :-)
I like it! As I said, is it okay to use some of your code?

Cheers,
Jon

Feel free to use any of my code - happy to contribute.

A few other notes:
 - I''m not sure if registering an external control should disable the
in-place clicking on the text or not. It sort of feels like it should,
so the widget has two very simple operating modes.  But I don''t know.
 - Yellow fade would be a much better solution than the spinning saving
thingy that I did.  With this stuff, making the right call for default
behaviour that addresses 90% of the usage is the way to go.  I''m
tempted
to make the argument that yellow fade is the right default behaviour no
matter what (like tada lists does).

I hear you on the dangers of over-generalizing things, I wrestle with
that myself quite often.

Thanks,

rahul

PS: think I forgot to cc the list, so I''m sending this again now.

-----Original Message-----
From: Jon Tirsen [mailto:jon.tirsen@gmail.com] 
Sent: Saturday, July 30, 2005 6:29 PM
To: Rahul Bhargava
Cc: rails-spinoffs@lists.rubyonrails.org
Subject: Re: [Rails-spinoffs] in place text edit

On 7/30/05, Rahul Bhargava <rahul@ntag.com> wrote:
> ah - great response.  thanks.
> 
> demos are here:
> http://www.instituteofthefuture.org/js/inplace.php
> 
> my responses:
> 
> * regarding an edit control widget (second demo on that page)
> point taken.  I''m not militant enough to make the usability guru
> argument that it must be underlined to suggest that it does something.
> adding an option to register another element as a controller would
> address my personal take on the interaction.  thanks.
You make a good point and seeing the demo I notice it''s certainly
going to work. I''ll add support for this. May I use your code if I
give you proper acknowledgment?

I think the default will still be to behave exactly like the Flickr
control, but this will definitely be an option.
> * regarding what to show while saving (third demo on that page)
> adding a hook for whileSaving or such would be great.  I did in fact
> use the widget :-P  my argument is that the "saving..." note
appears
> and disappears so quickly that the user never sees it (because the
> server could save and return so fast), and thus gets no intermediate
> confirmation of any sort of communication that would have saved what
> they did.  I''m expressing support for adding in a totally fake
delay
to
> give them that feeling that it''s doing something.  actually
I''m not
> certain myself that this is a good idea, but it felt right for the
tiny
> number of novice users I tried it with.  check out my hacked up
> example.
Interesting... When you''re talking to an app running locally or on the
LAN then it''s certainly going to be very fast. An effect like Yellow
Fade Technique would give a better feedback as it by nature sticks
around for longer. When the server is on WAN though the latency is
going to make "Saving..." appear for a longer time.

I''m not sure I like the idea of artificially making your app slower. I
really like the fact that an AJAX app is ultra-fast! :-)

I''ll add support for some sort of onLoading and onComplete callback so
you can plug in anything you like. Delays, Yellow Fade Technique,
effects and so on. Horses for courses. :-)
> * regarding a generic form flip-to-edit-mode widget
> thanks - I meant to ask what the goal of this in-place widget was, and
> you answered that.  it''s perfectly appropriate for the widget to
handle
> editing one text field, and that''s killer.  I''ll have to
think about
> what editing the whole form means and how I''d want to do it before
> doing a demo of that.
I initially wrote the widget because I had a page with a *lot* of
in-place edit elements. Having a hidden form for each of these
elements made the page several times larger then it needed to be!
That''s why I wanted a very simple control that created the DOM on the
client side. So I suppose that''s the scope of the control.

A generic flip-to-edit-mode widget is also interesting, but I think it
would have to be a different control. I don''t think it''s good
to
over-generalize things to the point that the basic usage is hard and
the complex usage is still complex.

Open to suggestions of course. :-)
> clearly I made a bunch of changes to things, maybe some of those are
> useful ideas to other folks.  fun stuff :-)
I like it! As I said, is it okay to use some of your code?

Cheers,
Jon