Reorderer components' name change

Jess Mitchell jess at jessmitchell.com
Thu Sep 25 14:10:43 UTC 2008


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
jess at jessmitchell.com
/ w / 617.326.7753  / c / 919.599.5378
jabber: jessmitchell at gmail.com
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
>> jess at jessmitchell.com
>> / w / 617.326.7753  / c / 919.599.5378
>> jabber: jessmitchell at gmail.com
>> 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                   a.cheetham at utoronto.ca
>>>>> Software Designer, Fluid Project    http://fluidproject.org
>>>>> Adaptive Technology Resource Centre / University of Toronto
>>>>>
>>>>> _______________________________________________
>>>>> fluid-work mailing list
>>>>> fluid-work at fluidproject.org
>>>>> http://fluidproject.org/mailman/listinfo/fluid-work
>>>>
>>>> _______________________________________________
>>>> 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
>>
>> _______________________________________________
>> 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/20080925/c02fc4cf/attachment.html>


More information about the fluid-work mailing list