Truncation Rules for Uploader, etc.

[Daphne Ogle]

Great point Erin and I agree that we should include some rules around  
truncation in component design.

I'm not sure we can create blanket rules though.  As you say, the  
rules that make sense for the filename during upload probably don't  
make sense for an announcement.  I think truncation rules will  
depend.  Perhaps it's time  to create something like a requirements  
template for components that include the various rules we want to  
think through (e.g. truncation, error checking, etc.).  Generally I am  
a big fan of requirements / spec templates.  They of course need to be  
flexible but having a structure to start with can be valuable in many  
ways:
- reminds us of the kinds of information that is important to include  
and think through
- don't have to spend up front time creating the structure of the  
document and can focus on the content
- can be a living template that captures good work practices we've  
identified between the various groups (e.g. developers tell designers  
they would always like to see X kind of information in a certain format)
- makes is easy for the audience to know where to find particular  
kinds of information in any requirements document for components

We could think of this as an iterative process and begin creating the  
template while we work on the upcoming components.  This probably  
aligns well with the work to think about design process, activities &  
artifacts.

-Daphne

On May 30, 2008, at 2:50 PM, erin yu wrote:

> Hi,
>
> This won't make the release, but I wanted to bring it up so we don't  
> forget.
>
> Currently with the Uploader, when you add a file with a really long  
> name, this happens:
>
> <Picture 103.png>
>
> The File Name column widens to fit the name and you can see neither  
> the sizes nor the remove buttons. This is an edge case, but when it  
> does happen, it looks buggy and confusing.
>
> It would be useful to have a set of truncation rules to be used in  
> our components, so we can see and distinguish the file names  
> reasonably well without affecting the column widths. In general,  
> when truncating file names, it is a good practice to show the last  
> bit and cut out the middle part, because the last part usually  
> contains the versioning and file type informations.
> e.g.	Chopping in the middle (good):				Chopping the end (bad):
> 	AwesomeOve...ect_EY.doc	 				AwesomeOverviewofFlu...	 	
>
> I think the rule commonly used by file systems is:
> n =  (x - e )/2 rounded down to an integer
> where
> n = number of characters to show from the front = number of char to  
> show from the back
> * these two can differ by a character
> x = column size defined by the total number of characters that can  
> fit in that column
> e = number of characters used for the ellipsis (...), usually two or  
> three dots
>
> But of course, if you are truncating an announcement title or  
> comments, there's no need to worry about this.
>
> Perhaps we can look into this more for 0.4.
> Erin
> _______________________________________________
> 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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20080602/e9feee16/attachment.htm>