Too much web design is focused on visual aesthetics and not on making things usable. Aesthetics has its place and not everything has to be intuitively usable. Cleanly designed web interface do look good. However, removing interaction clues in order to make something look neat and tidy is not always in the interests of the user. Making them difficult to interact with leads to more user frustration.
Microsoft's web based Outlook is a good example. Don't get me wrong, I think Outlook is great. I use it every day, both at work and for my personal emails. The web version is very functional and generally well thought out in my opinion. Yet, the way the scrollbars are implemented is frustrating. Here's a screenshot of Outlook's user interface to illustrate my point:
The layout is split into four columns. The application icons on the far left, the list of folders next to them, the list of emails in the selected folder and the content of the email selected to be read in the largest column on the right hand side. All four columns has a vertical scrollbar if needed. In the image you see it on the list of emails. There is no scrollbar in the email display column itself, because it is not needed. You would see it if the email was longer. However on the first two columns the scrollbar is needed because there is more content to scroll to. However you don't see it. It only appears if you hover over those columns, in which case it looks like in this image:
So what issues do I have with this?
First of all I do not see the point in hiding the scrollbars when hover is removed from the column. This is inconsistent. Some scrollbars are permanently visible. Some aren't. How do I know there are more folders in the folder list without hovering over them?
Hiding the scrollbars serves no purpose. They don't cover anything up when they do appear, so hiding them seems pointless. In addition they are so thin that even if they did cover up folder names, the amount covered would be minimal. Which leads me to the next point.
Because these scrollbars are so thin, I find them difficult use. I don't have a target area before hovering over the list of folders. So I move the pointer over the list. The scrollbar appears and I have to move the pointer back a little to get to the scrollbar in order to scroll. However sometimes I move too far and the pointer leaves the column. As it is no longer hovering over that column, the scrollbar disappears. Then I move the pointer back over folder list. It occasionally leads to the frustrating effect of me chasing the scrollbar. Why can't it just remain visible all the time?
Interestingly this design is not repeated in Microsoft's desktop explorer:
As you can see all the scrollbars are visible and they are much wider than in the web interface. Admittedly this a bit of an old school design. But it works and is much more usable than the implementation of scrollbars in the Outlook web interface.
Sometimes the old tried and tested design is better than the shiny new one.
Over the last few months I've made my hosting environment entirely serverless thanks to the help of GitHub, Forrestry and Netlify. Next, I wanted a cloud based development environment, so if I wasn't at my laptop and wanted to make a change, I could.
There were quite a few options, but the two that seemed to fit the bill for me were GitPod and GitHub Codespaces. The latter is not yet available to the general public. Whilst I did register for access, it's not yet been granted. That left me with GitPod. So I signed up, pointed it at my preview branch on GitHub, added a few config settings and I was done. I had a fully fledged development environment in the cloud, including full preview functionality. The IDE is basically Visual Studio Code in the browser. It is true that coding in a browser is not quite as user friendly as in a dedicated desktop app, but it's still very much manageable for me. I don't code that much, most of it is tinkering with existing code.
So now I have both my hosting and development environment fully in the cloud. The cost of all this? Surely all these services must cost something. Well, for my basic needs the monthly cost is zero. Nothing, zilch, nada!
Having moved my site from Wordpress to Eleventy hosted on Netlify, I was looking for a better editing experience than the one provided by writing my posts in a text editor or even in GitHub itself. I've settled on Forestry for now.
The web being the web, there are always opinions on which tool is better, which language superior or which hosting model future proof. The main argument for hosting appears to be traditional CMS (eg Wordpress) vs static sites and headless CMS (eg Netlify). A gentleman's barter was made between Matt Mullenweg and Ohad Eder-Pressman, with Eder-Pressman asserting that the JAMStack will be the dominant architecture by Sept 2025, overtaking Wordpress who currently host over 35% of the top 10K sites.
I've now moved my site over to Netlify. Having hosted it, at least in part, on Nearlyfreespeech for the best part of 15 years, I have decided to go fully serverless. This is not a slight on Nearlyfreespeech, I have had only positive experiences on Nearlyfreespeech and they will continue to host some legacy files of mine. The main reason for this switch is because I started using Eleventy, a static site generator, to build my site. This is great, it lead to much faster load times. But it meant I had to be on my personal laptop to update the content. I couldn't use an online service to update the site, like I could previously with Wordpress. At least not without a lot of extra effort and technical skills I don't really have. Sure I could create my content in GitHub, but to build and publish the site I needed to run the scripts that were on my laptop.
Jeremy Keith recently blogged about the great usability of the UKs Covid vaccination online booking process. Having recently renewed my UK passport online I can only second this. The UKs test and trace system perhaps wasn't world beating. But their Government Digital Service most defintely is!
This site is hosted on NearlyFreeSpeech.net. I've been using them since 2006 and I couldn't recommend their service highly enough. They are essentially a pay as you go service, where you pay for what you use. This makes them incredibly cheap for low use sites like mine. This site costs me less than $1 a month in hosting charges.
Finally a company that has got rid of all non-essential cookies and therefore does not need to annoy it's users with annoying privacy popups, often purposefully designed to confuse you into choosing the least private option. Well done to GitHub for removing all non-essential cookies and getting rid of privacy popups.
It's finally done. I migrated my site from WordPress to a static site generated by eleventy. I've also managed to get webmentions working of a sort. Many thanks for all the great help available on the internet.
I list here some sites I found especially helpful, but of course there are many others who gave me a nudge in the right direction.
Following this idea I saw on Chris Ferdinandi's site, of defining our stacks using our name, I present you the ROBIN stack:
This is a 10 parts series examining the WAD. In this final part of the series we look at articles 11 to 15 of the directive.
This is a 10 parts series examining the WAD. In this 9th part of the series we look at articles nine and 10 of the directive. The previous parts of this series are:
This is a 10 parts series examining the WAD. In this 8th part of the series we look at article eight of the directive. The previous parts of this series are:
This is a 10 parts series examining the WAD. In this 7th part of the series we look at article seven of the directive. The previous parts of this series are:
This is a 10 parts series examining the WAD. In this 6th part of the series we start going through the articles of the directive, covering articles one to six. The previous parts of this series are:
This is a 10 parts series examining the WAD. In this 5th part of the series we finish off going through the introductory recitals, starting with recital 47. The previous parts of this series are:
In part 1 of this series about the WAD, we covered the title and heading sections. In part 2 and part 3 of the series we continued by looking at the first 32 recitals. In this fourth part we continue going through the introductory recitals which give the background to the directive. The official text is available here.
In part 1 of this series about the WAD, we covered the title and heading sections. In part 2 of the series we continued by looking at the first 20 recitals. In this third part we continue going through the introductory recitals which give the background to the directive. The official text is available here.
In part 1 of this series about the WAD, we covered the title and heading sections. In this second part we go through the introductory recitals which give the background to the directive. The official text is available here.
No mentions yet.