Truncation Rules for Uploader, etc.
daphne at media.berkeley.edu
Mon Jun 2 18:01:43 UTC 2008
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
- 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 &
On May 30, 2008, at 2:50 PM, erin yu wrote:
> This won't make the release, but I wanted to bring it up so we don't
> 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
> 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.
> fluid-work mailing list
> fluid-work at fluidproject.org
Senior Interaction Designer
University of California, Berkeley
Educational Technology Services
daphne at media.berkeley.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the fluid-work