The Green Manalishi (With the Two-Prong Crown)
Posted on 9th May 2009
For quite sometime now, I like others I've seen on various forums, have got really irritated with one aspect of the colour scheme used on Linux when doing a directory listing. If you have the colour scheme enabled and haven't changed any settings, then likely as not, if you have any directory that is world writeable, then you probably won't be able to read the text.
When designing websites, it is common practice to use high contrast colours, as you want the site to be readable, and not cause headaches among your readers as they try to understand what you've written. Recently I was investigating some high contrasting colours, and found some good websites that explain what I mean.
With this in mind, why on earth would anyone think that blue text on a dark green background would be easily readable. Unless you get close to the screen and squint!
On Linux systems there is a application called 'dircolors' and if you're lucky enough on RedHat based systems, you even have the '/etc/DIR_COLORS' configuration file, so it is possible to try and figure out what needs to be changed. However, until now I've never manaed to find the offending attribute to change. After a lot of searching this morning, I finally found a site that explains all the short form and long form keys, and additional colours that can be used in the colour scheme, beyond the 8 foreground and 8 background colours. Even better it even explains the effects available. In most places only bold is mentioned.
So in the event anyone else has had the same problem with their directories disappearing before their eyes, take a look at Configuring LS_COLORS by David Newcomb. It turns out the offending key is OTHER_WRITABLE (or ow in LS_COLORS format). I've now set mine to something much more sensible (bold white on a blue background), and it's much much easier on the eyes :)
|
File Under:
design
/ linux
/ usability
|
Let Me In
Posted on 3rd April 2008
The problem with those that get high and mighty about username/password site logins, is that they often use examples where you really do want some degree of protection, not from yourself, but from others. Of the 16 Account Design Mistakes listed in Part 1 and Part 2 by Jared M. Spool, most include good ideas for developers, however, some use examples where the sites are quite right to be obscure.
Take #13 "Not Explaining If It's The Username or Password They Got Wrong", then proceeding to hold up Staples and American Express as the worst offenders. I'm sorry but if I have accounts with companies like that, then there is no way on earth I want them giving hints to crackers whether they got my username or password wrong. Those kinds of sites contain VERY sensitive personal information, not least of which is your credit card information. If Jared is that eager to share his financial information, I'm now wondering if he publishes it on his personal website. Could it be that perhaps the very security he ridicules actually protects him from identity theft?
Another is #16 "Requiring More Than One Element When Recovering Password", where a company requires some form of additional account information other than just your email address. Again this is a company that holds your credit information and by the sound of it some very personal information (such as my phone number). Does Jared post his personal phone number on his website? I doubt it as I assume he doesn't want all and sundry knowing it, thus exposing him to more identity theft.
Don't get me wrong, Jared does list some good thoughts about username/password site logins, but the context in which he uses to ridicule some sites and companies is grossly misplaced. The problem is that the author often thinks only in terms of making life easier for themselves, forgetting that you can also make it easy for those of a more malicious nature too. In all, or possibly nearly all, sites that I have a login for, the login is there to protect my account on the site from abuse. I know there are sites out there that only provide customisations with your login, but I don't use them. Even those that don't contain personal information, I would not want anyone to hack in to. If you're happy to make it easy for some one to login to your blog account and post spam, abusive or malicious content, then fine, make it easy. For the rest of us, we'd rather have some form of protection on the account that makes it a little harder for others to get through.
|
File Under:
design
/ rant
/ security
/ usability
/ website
|
Where's Captain Kirk?
Posted on 6th June 2007
I've just seen the unveiled logo to promote the 2012 Olympic Games in London. Hideous is one word to describe it, although there are several more I've read. It does amaze me how companies and organisations place so much trust in marketing and advertising companies, when their own staff or the general public are often only too willing to help and suggest much better alternatives. The Daily Mail has a gallery of reader logos and in the paper there are several more that are far better than the official design.
I'm actually quite surprised that this wasn't opened up to a public competition, perhaps run by Blue Peter who have a history of helping to create classic images for this sort of thing. It would have been cheaper for a start, a prize of a few thousand pounds would have been far less than the £400,000 spent on the effort a "professional" company could produce. I'm off to sign the petition at gopetition.co.uk, not that'll do any good, but hopefully someone will see sense and realise that such a bad wave of criticism is not good, and will likely mean a distinct lack of support from the very people who are supposed to be benefiting from the event, the British people.
The other thing that gets me, is that it is now unlawful to use our capital's name and the year the Olympics will be held there, together in anything that consistutes public material (e.g. a website). Read their rules to see how far they take absurdity. Technically then I cannot legally promote the games, mention the website or even link to it. So maybe I should remove that last link and hope you can find it! Idiots. I can understand why the branding should be for the sole use by the sponsors for merchandising, promotion and to label products, but to say that unless I gain the permission of the committee I am not allowed to mention the name or use the logo to link to the official site is just too daft to mention. But then again I'd not want to advertise the current logo anyway :)
|
File Under:
design
/ london
/ olympics
/ rant
|
The Frayed Ends of Sanity
Posted on 1st June 2007
XWiki would seem to be in dire need of some sanity. When I upload a file, I expect to get an appropriate error message if it fails, or better still tell me before hand if it's likely to be too big. I don't expect there to be a two huge great Java exceptions thrown back at me. Thankfully, I'm a technical user and can decipher the program (the image was too big), but other users might not be so understanding.This goes back to what I posted yesterday, don't send users down broken paths. If there are constraints tell them!
However, there is also another issue with sites that upload photos like this. If you have a limit on the size of the photos, resize the image. It isn't hard. This is what Labyrinth does, so although your original image might be 1280x1024 and be over 1MB, it will get saved as something like 800x800 or perhaps 150x150 for thumbnails all automatically, without the user having to worry about it. Why make the user jump through hoops, when you can so easily add a feature like that yourself?
The problem here though looks like the XWiki (or at least this installation of it) uses the database as a file store. The Java exception errors are from JDBC finding the data too big to store. Why is an image (or any media file) ever stored in the database? I've come across this idea a few times before and have never understood the point. Use the filesystem of the OS to store files and databases to store your textual content. You aren't going to search the content of the data block in the database, or if you are then I seriously doubt you get any benefit over using tools dedicated to accessing and interrogating files at the OS level.
Maybe it just comes down to the fact that Java programmers seem to want to try and do everything themselves. I've come across this several times when I was forced to use Silverstream many moons ago, also written in Java, and seem to be a mantra of Java in that it's the only tool for the job, even if it isn't.
|
File Under:
design
/ usability
/ web
|
Don't Come Around Here No More
Posted on 31st May 2007
Recently I joined the Facebook community. Seeing as several coworkers were prompting me, and it looked to be a more social version of LinkedIn, I thought I give it a try. For the most part it is a fun site, although there are a few dodgy parts, but you kind of expect someone is going to try and push the barriers of taste on a site like this.
However, there was one aspect that really irritated me the yesterday, that although I found it on Facebook, I've come across similar things on several sites over the years, and is a failing of the web designers to actually understand their audience. In web design there is a lot of emphasis on usability for a very good reason. It is absolutely pointless having a beautifully crafted web site if your potential users can't use it. Now most designers do get the idea of keeping the navigation clear and easily available, and generally layout has gotten less busy over the years, but usability is more than just understanding where everything is.
Your site needs to be functional, even if that means you only have static pages that provide other ways for your users to interact with you, such as providing a contact address. To me, functional means doing something useful and not irritating your user base.
The part of Facebook that fails this part of functionality, and irritates the hell out of me, is taking your users on a trail that is a pointless dead-end and completely wastes the users time even bothering to follow it. If you have ever clicked to 'Add a friend', then you will most likely be presented with a box that requests you to enter the CAPTCHA. Just above the box is a link that implies you can forego this CAPTCHA if you verify yourself. So I thought I do just that. The next page then asks you for your mobile phone number. As I didn't want to give them my personal mobile number, I thought I'd use my works mobile. Unfortunately I'm very bad at remembering phone numbers, so it took me a few minutes to find it. I entered the number and click to get verified. I was then presented with an error message which to me, reading between the lines, said "no you dolt, an American mobile phone number, because you know, obviously ONLY the interesting people are in America". No it doesn't actually say that, but it might as well have.
If you offer a piece of functionality that is only available to a small sliver of your potential audience, SAY SO! It isn't difficult. At the CAPTCHA they could so easily have in brackets "(available for US residents only)". It would have be midly disappointing that it was only available to a select group, but at least I wouldn't have wasted my time trying to use functionality that I was never going to be allowed to access, or felt insulted by the implication that I should have known this.
|
File Under:
design
/ usability
/ web
|
