worms indeed. I might have opened this can. And now I'll close it
and hold my breath.
We're going to go with:
Reorderer
List Reorderer
Image Reorderer
Layout Reorderer
and we'll change now for 0.5 and we'll employ Colin/Anastasia/
Michelle's method of
The documentation
should make it clear that the older functions will be moved out of
core and into a compatibility library for 0.6. Then we'll gradually
transition users to the new API..
The reasons are, as Gary brought up, the Reorderer does more than the
action of drag-n-drop (mouse users only) and it is fair to say
(maybe?!) that it is a thing that Reorders, ergo The Reorderer.
We'll need to continue to work on making our naming convention
meaningful to people who aren't familiar with our familial components.
Thanks for all your comments!
Jess
~~~~~~~~~~~~~~~~~~~~~~
Jess Mitchell
Boston, MA, USA
Project Manager / Fluid Project
[EMAIL PROTECTED]
/ w / 617.326.7753 / c / 919.599.5378
jabber: [EMAIL PROTECTED]
http://www.fluidproject.org
~~~~~~~~~~~~~~~~~~~~~~
On Sep 25, 2008, at 8:18 AM, John Norman wrote:
In fear and trepidation of opening a horrible can of worms, I just
thought I'd point out to me that the word "reorderer" doesn't
actually convey any meaning. It is clearly a word that the project
has come to agree encapsulates the work done, but to the person
unaware of the work done, it doesn't say much. I tried a
Google:define and got:
No definitions were found for reorderer.
Suggestions:
- Make sure all words are spelled correctly.
- Search the Web for documents that contain "reorderer"
The result of the web search of course puts the Fluid pages at the
top, which gives you the opportunity to define the term. But I
didn't have any understanding from hearing the word before searching.
I wonder if it is worth saying in two sentences what you want each
name to capture and maybe asking people outside the project what
they would think are words that capture the meaning in those 2
sentences.
Probably overkill. Maybe best to invent a word and define it, but
the names should come with pithy definitions alongside if the words
are unknown to the audience.
John
On 24 Sep 2008, at 21:35, Jess Mitchell wrote:
Before it happens, I'd like someone who was involved in the naming
of Layout Customizer to weigh in on that name change. More than
the other names, that one has caught on to a certain extent. I
know I use it in conversation all the time and a good bit of our
documentation early on used reorderer and layout customizer
interchangeably (though I know that shift reflects some fundamental
code changes). Is there a reason to change it?
BTW +1 Image Reorderer
Thoughts?
Jess
~~~~~~~~~~~~~~~~~~~~~~
Jess Mitchell
Boston, MA, USA
Project Manager / Fluid Project
[EMAIL PROTECTED]
/ w / 617.326.7753 / c / 919.599.5378
jabber: [EMAIL PROTECTED]
http://www.fluidproject.org
~~~~~~~~~~~~~~~~~~~~~~
On Sep 24, 2008, at 4:13 PM, Daphne Ogle wrote:
I change my vote to Image Reorderer. It wasn't on the table when
I initially voted :)
-Daphne
On Sep 24, 2008, at 12:32 PM, erin yu wrote:
Chatted with Anastasia - she thinks renaming (at least on the
wiki) is a necessary step, but we'd have to worry about backwards
compatibility. Renaming in the code wouldn't be terribly
difficult, but we'd have to be thorough.
Here are the responses so far.
Layout Reorderer
+ 1: Erin, Anastasia, Colin, Gary, Daphne, Allison
-1: Eli
Thumbnail Reorderer
+1: Erin, Anastasia, Colin, Gary, Daphne
-1: Antranig
Image Reorderer (as opposed to Thumbnail Reorderer)
+1: Gary, Erin, Allison
Erin
On 24-Sep-08, at 2:34 PM, Anastasia Cheetham wrote:
On 24-Sep-08, at 2:19 PM, Colin Clark wrote:
An alternative approach would be to provide an optional
JavaScript
file that offers backwards-compatibility for such API changes.
This
is very much inspired by John Resig's approach to API change in
jQuery.
Hm. I'm not sure I understand what this file would contain - the
old
APIs wrapped around calls to the new APIs? I'm looking at the
jQuery
code, and I don't see anything that looks like what you're talking
about?
--
Anastasia Cheetham [EMAIL PROTECTED]
Software Designer, Fluid Project http://fluidproject.org
Adaptive Technology Resource Centre / University of Toronto
_______________________________________________
fluid-work mailing list
[email protected]
http://fluidproject.org/mailman/listinfo/fluid-work
_______________________________________________
fluid-work mailing list
[email protected]
http://fluidproject.org/mailman/listinfo/fluid-work
Daphne Ogle
Senior Interaction Designer
University of California, Berkeley
Educational Technology Services
[EMAIL PROTECTED]
cell (510)847-0308
_______________________________________________
fluid-work mailing list
[email protected]
http://fluidproject.org/mailman/listinfo/fluid-work
_______________________________________________
fluid-work mailing list
[email protected]
http://fluidproject.org/mailman/listinfo/fluid-work
_______________________________________________
fluid-work mailing list
[email protected]
http://fluidproject.org/mailman/listinfo/fluid-work
