In a further effort to make users perfectly comfortable with our application, this article will explore two functions we can use to make text more readable for the user. We will examine how to neatly trim long strings without chopping words, how to redefine dates into a more human format.
Contributed by Justin Cook Rating: / 63 June 22, 2004
If you've read any of my past articles, you know that I'm big on usability. The applications we design and build should work for the users, not vise versa. To this end, we strive to place as few limitations on the users as possible, and give them information in a manner that they are accustomed to receiving.
To make these points a little clearer, I'll explain two situations and then give the functions to help us with those situations. These situations are: limiting string length and providing readable dates.
Please Limit Title to 50 Charact...
Notice the heading of this section. This is a very common result of misapplied discipline. You see, we as the developer understand that in a given situation, a title of only 50 characters may be appropriate, as anything longer could crowd the page, or cause other problems. So you have two choices:
You can limit the number of characters the user can type in, either server-side or on the client browser (or both). This has the unfortunate consequence of causing the user severe frustration when the input box simply stops receiving input at 50 characters. They call tech-support to complain that their keyboard is broken, realize it's not, then call you only to find out that they're limited to 50 characters, and then suffer further frustration at having to shorten their title to a far less descriptive slew of words. So no, this isn't a great option. Just think of eBay, wouldn't you just love to be able to leave longer feedback remarks?
Let them type in whatever they want, then when you're surfacing the string on a web page, you just chop it at 50 characters, and tack on a little '...' at the end to signify that it's actually longer. Of course the problem with this is that words get hacked in the middle, as in the case of this title.
So, as neither of these options seem that great, we've got to come up with some kind of workable solution. And so I have! In harmony with ASP's inherent Trim, RTrim, and LTrim, I've named it NeatTrim. You can use NeatTrim to accept a string of any length, and trim it to the space nearest your desired trimming length. I'll show you the code, and explain the use and benefits thereafter.
'============================================
Function neatTrim( strToTrim, desiredLength )
'=============================================
strToTrim = trim( strToTrim )
if len( strToTrim ) < desiredLength then
neatTrim = strToTrim
exit function
else
if inStrRev( strToTrim, " ", desiredLength ) = 0 then
First, the string is trimmed, removing any whitespace at either end. If the string is actually longer than what you've specified as the maximum desired length, the whole string is returned. Otherwise, we move on in the function, trying to find the nearest space to the desired length. This is accomplished by employing ASP's inStrRev to search through the string in reverse. We give it the desired length, and that's where it starts searching, backwards. The reason for doing it backwards is that you'll only end up with a string slightly smaller than the desired length, but never larger.
If no space can be located, then we are forced to chop the string. Though this may not seem too desirable, we really have to do it, otherwise the string wouldn't be shortened at all. It shouldn't cause too much grief, as the only case where this would happen would be with long strings not containing words, as with serial numbers.
For most other string, this will work perfectly well. We use the character '…' because it produces the '...' in the width of only one ASCII character, and not three full periods. You can adjust this as you see fit.
A sample use of this would be:
strLong = " This string is too long! "
strTrimmed = NeatTrim( strLong, 13 )
response.write( strTrimmed )
This would produce:
This string...
Now, for the user's sake, it would be a good idea of somehow indicating what the full string really is. This can be done through the HTML 4.0 attribute of 'title'. Here's an example:
With that code, they will still see the neatly trimmed string, but when they move their mouse over it, they get the full string in the little 'title' popup. Now let's move onto the second.
When you print out a date in ASP, by default you'll get the format of MM/DD/YYYY. There are all numeric references, and they are just plain annoying. Let's face it, most of us hate having to translate in our heads which month '07' is. Even though we've known all our lives that there are only 12 months, and have had many years to remember their numeric order, we still catch ourselves thinking “January, February, March, April...” and so on, all the while ticking them off with our fingers.
Now, that takes time, and if I'm quickly glancing at a screen of data, to obtain specific information, I don't feel like wasting time figuring out what the date means. So to cater to this, I've built a function to modify and re-deliver a date, in a format that we humans are most comfortable reading and referring to. It's called niceDate(), and here it is:
'============================================
function niceDate( dt, excludeDay )
'============================================
if not isDate( dt ) then
niceDate = ""
exit function
end if
dim d
d = ""
select case Weekday( dt )
case 1:
d = "Sun "
case 2:
d = "Mon "
case 3:
d = "Tues "
case 4:
d = "Wed "
case 5:
d = "Thur "
case 6:
d = "Fri "
case 7:
d = "Sat "
end select
if typeName( excludeDay ) = "Boolean" then
if excludeDay then d = ""
end if
d = d & MonthName( Month( dt ), true ) & " " & Day( dt ) & ", " & Year( dt ) 'no carriage return here
niceDate = d
end function
In essence, it's fairly simple. There's the initial type-checking, where we prevent errors that would result in trying to extract date information from a non-date string (the good ol' type mismatch error). Then we move into a select statement, where we figure out which day of the week it is, and provide the human-friendly version (after all, nobody knows they hate day #2, they just know that they hate Monday). You also have the option to exclude the day from the output, which is a nice way to shorten the resulting string.
At the end, it's all tacked together in a 'nice' format, hence the name of the function. Here's how you'd use it:
dim strDate
strDate = date()
response.write( strDate )
would be: 05/31/2004
dim strDate
strDate = date()
strdate = niceDate( strDate, false )
response.write( strDate )
would be: Mon May 31, 2004
Now, wouldn't you agree that this is so much nicer? No more finger counting!
And of course, to exclude the day, we would do this:
dim strDate
strDate = date()
strdate = niceDate( strDate, true )
response.write( strDate )
This would result in: May 31, 2004
No doubt you agree that users would be far more comfortable reading dates in this format, and therefore happier with your application!
Conclusion
When designing and building an application, we always have the objectives - the work that we need the application to do – first in mind. But if we can train ourselves to couple that objective with the needs of the users, greater acceptance of the application is far more likely to take place.
The two methods I've outlined in this article are key to this approach. I have found them very useful, and honestly I package them in a library of handy functions to re-use in basically every application I work on.
The first will really aid in the visual design of the system, as long strings will never crowd other information. This is one of those things where people will not really notice it, not being constrained to any number of characters. It will just happen, and they will just be okay with it.
With the niceDate function as well, people won't notice it. That's because they're used to dates in that format. They will never say “hey, there's a date like I'm used to!”, they will just read it an move on.
That should really be our goal in usability design. The tools we implement should be done so in such a comfortable manner that nobody really notices, they just happily work away, and move on with their busy lives without ever having to call us in frustration. Feel free to share any other functions that you've developed in this regard in the forum!
/ 63 
Implement Gzip and Deflate Compression in ASP.Net
