Code, Design and Random Thoughts

Today I want to reveal a ‘hidden’ feature of Übersicht that has been available since version 0.2. The reason for this secrecy is that it is in an early beta state and still somewhat cumbersome to use. However, the release of Mac OS X Yosemite is nigh and this will probably be a welcome addition to match the visual appearance of it. So I thought, better to get some people using it and get some feedback.

The hidden feature I am talking about is background filters. OS X Yosemite is full of them - most commonly blur filters. What they allow you to do is having beautiful translucent effects without sacrificing usability. Without filters, other content shining through translucent elements offers too many distractions. However, with the right filters you don’t so much see other content, but rather get the impression that the UI reacts to surrounding colors ever so slightly.

get your blur on

So how would one recreate Yosemite’s filters in Übersicht? Of course CSS3 filters have been available for use since the first release. The problem with CSS3 filters is that they can only be applied to a DOM element and not what’s behind a DOM element. To make matters worse, usually what’s behind Übersicht widgets is the desktop wallpaper, which is not even part of the same App, let alone the Übersicht DOM.

To work around this issue, I’ve created a way to choose a dedicated DOM element and make it display a slice of the desktop wallpaper. The slice is chosen so that it exactly matches what would normally behind said DOM element. To understand what I mean, lets dive straight into an example.

setting up

The image to the left shows a simple widget with a translucent background and no filters applied. It has only a single DOM element that shows the widget content.
In order to get this widget ready for background filters we first need to create a more complex DOM structure:

We’ve now created a canvas element which will later draw the wallpaper slice, and a content element which will hold the widget content and sits in front of the canvas element. Of course we need some CSS to make this work, which comes down to:

This applies the background color to the content element and makes the canvas span the entire widget, sitting behind the content. Note that using width and height is important or otherwise the canvas will have a default size 300xsomething pixels.

This code will make the widget look identical to the previous code: The canvas element is completely transparent so there is nothing to see and nothing to apply the blur filter to.

drawing the background slice

To make the canvas draw a slice of the wallpaper we can use the the new uebersicht.makeBgSlice method. It expects a canvas element as an argument and will measure the elements size, ask the App for a wallpaper slice of that size and finally draw the slice. For it to be able to measure the canvas size, it needs to be called after rendering has happened. For this we can use the new afterRender property, which - as the name suggests - gets invoked after render. This gives us following code:

The result can be seen to the right. It looks pretty much what we are looking for, but keen observers will note that the background looks less blurred and more transparent towards the edges. This is a common problem with blur filters (for reasons I will not go into detail here) and corresponds to the blur radius we chose - 10px in this case.

the final 10px

To get this just right we need to compensate for the 10px blur radius by growing the canvas element
10px in every direction. Luckily we have Stylus to aid us here; we can make the blur radius a variable and add it to the canvas size. The code and result are shown below:

caveats

As you have probably noticed by now, getting this to work is a somewhat tedious process which could probably be streamlined. Some other issues remain, that might be harder to fix, though. You will notice a delay when switching to a desktop with a different wallpaper until all your filters display the new wallpaper image. Also you will notice a spike in CPU usage while the App processes the new wallpaper.

For these reasons, please be careful when using this feature and expect some changes in the future. In the meantime, happy styling and experimenting!

A new version of Übersicht has been released today, which brings a much requested feature: screen control. For those of you with multiple monitors, you can now select which monitor Übersicht runs on.

It should also remember which monitor(s) you used last and use it again whenever it is available. Note that it doesn’t remember the exact monitor, but rather which port the monitor was connected to. So if you connect a different monitor to the same port, it should use that one.

The screen-shot to the left also shows another new feature: manual refresh. You can now force your widgets to refresh manually, which is handy when you just woke your machine from sleep and don’t want to wait for your widgets to update.

Finally, there also have been improvements to error reporting to aid you in writing your own widgets. CoffeeSCript and Stylus compile errors were previously only logged to the system log, but now they will appear in the developer console as well.

This is the first release that has seen some community involvement and I’d like to thank every one who helped out! Special thanks go to Guillaume Boudreau and Siemen Sikkema.

Earlier today I released Übersicht, a little Mac app I originally wrote to scratch my own itch. It is essentially like GeekTool, which lets you run system commands and display their output on your desktop. The main difference that widgets are written in HTML5, which was originally motivated by these two main reasons:

I can plug in a different monitor without my widgets breaking

I can easily write my own widgets

So in essence the app is just a large WebView that is glued to your desktop and widgets are little snippets of HTML+CSS+JS. Of course you can’t run system commands from within a WebView, so the app comes with a NodeJs backend. For more details on that, you can checkout out the slides for my talk at the local Amsterdam JavaScript Meetup.

Of course, also checkout the app itself. It is released under the GPL license and the code can be found on GitHub!

Sometimes building web apps feels like trying to build a house of cards while the browser might pull away the carpet from underneath you at any moment. Text entry on mobile is one of these issues were you, as a developer, have very little control over what you want to achieve versus what the browser thinks it is best for you.

Mobile browsers have a reason for this of course. When the mobile web came about, websites and web apps where not designed with a small screen and a software keyboard in mind. In order to still provide a decent experience when entering text, mobile browsers had to come up with some solutions. For Mobile Safari that solution was to overlay the soft keyboard on top of the page and scroll the page so that the focused text field is in center of the visible space above the keyboard.

dont push me, ‘cause …

While this works great on normal websites, in your carefully crafted web app you might run into something like this:

This might not seem like a big deal at the first glance, but when trying to create a seamless, near-native user experience, this can ruin your day. Submit buttons and other form elements that were carefully placed to be visible and easily reachable when entering text are now scrolled halfway off the screen. In combination with the unexpected movement it really makes the app feel broken.

window.scrollTo to the rescue

So what can we do about this. There is, to my knowledge, no clean work around. A lot of default behaviour of the browser can be tweaked using css, some kind of event.preventDefault() or by other means, but this isn’t one of them. What we can do, however, is to reset the scroll offset using javascript (or coffeescript in this case), so something like this:

1

$(textareaEl).on('focus',function(){window.scrollTo(0,0)});

This is assuming that your web app takes the whole screen space and hides the address bar. However, it doesn’t quite work; the browser scrolls just slightly after the focus event fires, so the page scrolls anyway. Using a setTimeout works, but you rely on a magic number, plus it is hard to catch it exactly when it scrolls, so that there is a visible jump happening before the text field moves back in its correct position.

hard to catch

It turns out, that if you focus the text field programatically, there is no delay before the page scrolls, so the onfocus handler catches it just in time.

So the final solution boils down to:

stop the browser from focusing the textfield when the user taps it.

focus the text field programatically.

scroll window back to top when the focus event fires.

I need to emphasise that this is only a valid solution if your are dealing with a full-on web app, which is sized to fit the screen and is not user scalable. Double tap zoom, or pinch zoom will break with this approach (just on the text field, not the entire site)!

bolting the carpet to the floor

In order to stop the browser from focusing the text field we need to preventDefault on touchstart (touchend should work as well). This means we have to provide our own custom tap handler, since the default click behaviour won’t get triggered. The final solution could look something like this:

varonClick=function(domEl,clickHandler){domEl=$(domEl);// make sure we have a query objectvarstartTime,startPos,canceled;domEl.on('touchstart',function(event){// this prevents the browser from firing a click event and// focusing the text fieldevent.preventDefault();canceled=false;startTime=event.timeStamp;startPos={x:event.pageX,y:event.pageY};});domEl.on('touchmove',function(event){vardx=event.pageX-startPos.x,dy=event.pageY-startPos.y;// cancel click if finger moved more than 40pxvardistance=Math.sqrt(Math.pow(dx,2)+Math.pow(dy,2));canceled=canceled||distance>40;});domEl.on('touchend',function(event){if(canceled)return;// don't trigger click if finger rested longer than 500msif(event.timeStamp-startTime<500)clickHandler();})};

And there you have it; the text field stays in place, solid as a rock. We’ve bolted the carpet to the floor and can now happily continue to build our house of cards.

Mind you, this solution is for iOS only, so on Android or other mobile platforms/browsers it won’t work and even break things. There are other solutions for these platforms, which I won’t go into further detail here.

Finally, do remember that you are breaking default browser behaviour, which exists for a reason. So know what you are doing or else you might significantly reduce the usability of your app! Having a textfield stay hidden behind the soft keyboard, or preventing other necessary user interaction is hardly ever very user friendly ;).

Here is to a fresh start!

Since posterous shut down I had to migrate my not-so-active blog, but wasn’t successful with importing all my old posts so far. Many of them are probably not worth the trouble. I do hope to move over the more interesting posts some time soon, though!