Things the “T” does not stand for, part 1. Made with Inkpad for iOS.
TL;DR: grab a bookmarklet that adds “download video” links to Sakai videos.
In several of my classes at UNC, we use an education CMS called Sakai. For one of my online courses, lectures are posted as videos in Sakai, which is really convenient. However, the screen size options are “really tiny video” or “full screen”.
I wanted to download the videos to watch them in an external video player so that I could watch the video on half my screen and take notes on the other half. After digging through the page source, I finally found the actual video URLs. I don’t want to have to do that every time, though, so I created a bookmarklet that adds links after each video that link directly to the video for downloading.
I’ve only tested this in Chrome, but it works fairly well so far. The videos before:
The videos after running the bookmarklet:
The bookmarklet is in a gist on GitHub (link at the top of this post).
On my winter break after my first semester of graduate school, I did a little personal research project. The project’s goals were:
And, here are the results: Web Assets & Benford’s Law. It was fun, and I enjoyed it so much more than those assignments that are required in a classroom. :)
As defined in my previous post, Gray Plating is the overuse of gray in a user interface when it is detrimental to the user experience. Today, while reading about an app on the iTunes store, I found a good example of this problem on apple.com.
Reading the body text that describes the app Comic Zeal, I found the text to be a little hard to read in my living room, with natural light in the environment. Here is a screenshot of the body text:
If we plug the foreground text color (#898989) and background color (#ffffff) into Lea Verou’s awesome WCAG 2.0 Color Contrast calculator, then we get a result of 3.5, which partially explains the problem with the contrast. A 3.5, as the tooltip help text states, means this contrast “passes AA for large text (above 18pt or bold above 14pt)”. The website’s body text is 12px, or roughly 9pt, on my 1680x1050 resolution MacBook Pro screen.
At a font-size equivalent to 9pt, the iTunes app store body content fails to meet the WCAG 2.0 guideline 1.4.3 on minimum contrast, unless users resize the text themselves. It’s a good thing I’m nearsighted at this age, but for 80 year old me, and for others that currently don’t have as good of vision, this kind of Gray Plating is a real problem.
Despite the fact that responsive images may one day fix the bandwidth problem for images, I still think it is worthwhile to explore a simple alternative for certain types of sites. On mobile devices with slow network connections, images can take up a huge amount of the page weight for a single web page. I started discussing in my previous post a simple idea: just link to the images by default and let the user click the link to show the image. The user’s click could send a normal HTTP request, or an AJAX request to fetch the image and put it in some sort of modal dialog.
In practice, it might work for something like this ArsTechnica article from last year.
With images, this page is 14 HTTP requests and it has 896KB worth of images in the page.
In a user-activated version, with the images as links, it would look like the following image.
This version contains 11 HTTP requests, with only 8.6KB worth of images for decoration.
The first example is 1.1MB and the second example is 221KB. That is an 80% reduction in total page weight by just making the body images links. I think this kind of page weight reduction would be worthwhile for blogs and news sites where the main draw of the site is the written content, not the images. An option not to show these large images could be saved in a cookie, much like the option to “view mobile” or “view desktop” is saved on these kinds of sites currently. This is a really simple idea, and users may not find it worth the bandwidth savings having to click for their images, but I think it may be worth it in some contexts.
I’m not sure when car manufacturers started making seat belts in the backseats of cars not interchangeable, but it has to stop. If you’re not familiar with this, find a car built in the past few years and see if the passenger side seat belt buckle can fit in the receptacle on the driver’s side. Most likely, it can’t. I assume this is some sort of affordance that car designers have put in place to “help” passengers figure out which seat belt buckle fits with which receptacle. Googling hasn’t returned any decent results as to why this design decision was made.
My gripe is that the safety gains from enforcing one buckle to one receptacle do not outweigh the inconvenience of trial and error when trying to buckle up in the back seat. Beyond just inconvenience, though, bigger individuals can’t use two seats this way, because the middle receptacle won’t accept a side seat belt buckle.
Obviously, this is a minor thing and definitely a first world problem, but being related to design and engineering I felt like it was appropriate material to cover.
Idea: Coffee stirrers made of metal that change color based on drinkability of the coffee.
The new iOS 7 fade-in animation that occurs when turning on the device seemed slow to me, or at least slower than in iOS 6. So, I wanted to run a pseudo-scientific experiment to see if my perception was correct (“pseudo-scientific” due to the small sample size). I compared my iPhone 4S with iOS 7 to my wife’s iPhone 4S with iOS 6 in terms of “time to home screen”, which I defined as the time between pressing the power button, unlocking the screen, and waiting for the icons to come into place on the home screen.
For iOS 6, 5 runs: 2.11, 2.2, 2.07, 2.12, 2.06 (measured in seconds), with an average of 2.11 seconds.
For iOS 7, 5 runs: 2.3, 2.33, 2.51, 2.54, 2.47 (measured in seconds), with an average of 2.43 seconds.
The difference comes out to .32 seconds of extra time waiting on animations before getting to the home screen in iOS 7. Now, that’s not a whole lot of time; it’s not even a full second. However, this is a task that users will do several times a day, perhaps even several times an hour, and that means extra fractions of a second wasted over millions of people. When a user interface has a major update, it should take less of our time to use it, not more.
Software developers always have to be mindful of avoiding Gold Plating. Developers, though, are not the only team members that can go overboard on a project or feature. When visual designers use aesthetics to emphasize “beauty” over usability, they overstep their duties to the users of their software.
One tendency I see now is to over-use the color gray throughout an interface—John Brandt discussed this in his post What’s with all the gray? I propose the phrase “Gray Plating” (or “Grey Plating” if you prefer the non-U.S. spelling) for the overuse of this visual style when it is detrimental to the user experience.