Judging a book by its cover
Posted
If you’re in the market for a new SaaS based application there are a lot of dimensions to consider: features, pricing model, vendor stability, future proofing and more.
For products that don’t offer free trials, getting answers to these questions can take work: you have to submit your contact details to a mailing list, align calendars, sit through demos.
If you need to narrow the field down, the login page for the application can tell you an awful lot about how the application is built, what stage of growth the product is at and maybe hint at the companies priorities: all without having to talk to anyone and getting your email on a list.
So, dig out the login page for an application and lets take a look.
Responsive?
So what do you see? Aesthetically does the login page look like an app you’d want to use? Or is it ‘developer pretty’. Has someone thought about alignment of text in input fields or was it just thrown together?
Flip on mobile viewport and see what happens: does the page elegantly resize? Throw an error that the app shouldn’t be used on cell phones, only in Internet Explorer? Or completely ignore it, expecting you to pinch and zoom?
Accessible?
Accessibility is all about using the tools HTML gives you to make a page accessible to those with disabilities. There’s plenty of tools that will check this for you. Point the page at something like Wave and see what score the page gets. In isolation, the score may not mean much to you but if you compare a few sites you’ll soon figure out which companies care even enough to algorithmically test for accessibility.
Another form of accessibility: is the page compatible with a password vault? Or are the developers actively trying to defeat one (cough_ most banks _cough).
Fast?
How quickly does the login page load? Were you waiting, was there a modal dialog? Or did the page pop immediately into existence? If you wish you can quantify page load using a tool like Google PageSpeed - but beware, some vendors will pre-load for post login performance which can make first page performance score worse.
Back when I worked on web based products we would argue about this a lot. The thinking went that customers paying a subscription are not as sensitive to site performance as perhaps they would be e-commerce.. I always felt that was baloney: they’ve paid for the product so it should be as fast as we can make it so they waste less time.
A site that’s fast shows that someone senior at the vendor cares.
Peek under the hood
Next, right click and view source. Some things I look for:
- Is it tag soup? That indicates either an older application that hasn’t had much love or (out-sourced?) development by a team that hasn’t been told to or doesn’t care. It’s not just about the readability: tag soup is a disaster to maintain: expect less frequent releases.
- Is there inline CSS? There’s rarely a good excuse for this: it suggests someone couldn’t figure out the site stylesheet so just did a quick override.
- Do
<!-- HTML comments -->remain in the page? Amateurs! This isn’t Hello World. - What about references to static content in the
<head>of the page: do they contain build numbers? That suggests a well architected site where the developers have thought about the need to roll releases forward and backwards in a way that doesn’t break user experience. - Is a CDN visible? Sometimes it won’t be unless you start to do DNS lookups, but if the company is using a CDN that’s a good sign they care about the performance of their application. Anyone who tells you a CDN isn’t worth it doesn’t know what they’re talking about.
- What format is the company or product logo? Are they old skool GIF, WebP or sexy SVG? The latter is the best both more slimline as well as better on high dpi screens. GIF logo? App is ancient.
- What’s the page URL? A PHP page? Cgi-Bin? ASP? That’s some old stuff right there. The product might be excellent functionally but it’s clearly not getting much investment.
- If you’re really feeling it, look at the page response headers: is there cache control? Or is everything set no-cache because the tech team couldn’t figure it out?
Boiling it down
Ultimately the login page can tell you a lot about the vendors priorities:
- Older technology and/or aesthetic? The product is a cash cow: The vendor isn’t spending on it because they don’t see any need: the dollars are going somewhere else. It may do exactly what you want but don’t expect any of those ‘roadmap’ items you get promised to be delivered any time soon.
- Great look but lousy implementation under the hood? Marketing is in charge: the priority is sales not long term sustainability of the product. The engineering team have lost the argument.
- Simple and elegant under the hood? Engineering is in charge: Expect the product to rapidly iterate with some rough edges but know that if its not working right now it will be in five minutes.
Clearly I have my bias. I believe a well built product is easier to maintain and enhance. All else equal that means better long term customer satisfaction and retention. If you arrived at a new vendor’s office to find a beat up reception area you’d wonder about the priorities of the operation. A login page is no different. First impressions count.