by Alex Holt | Nov 17, 2012 | Dev, Web |
I’m in the (very slow) process of porting a few of my more content heavy sites from their old CMS systems across to docpad and http://node.js. One of the things i’m doing is converting all my CSS to SCSS – which i’ve previously always done by hand. However i just found this:http://css2sass.heroku.com/, which allows me to paste in CSS and it will actually convert it to SCSS. This includes intelligent rule nesting...
by Alex Holt | Jun 27, 2012 | UI/UX |
Google finally got around to updating their iOS app – it now supports push. Since I’ve blogged a bit about Sparrow recently, I figured I’d give everyone a quick update on where my iOS mail usage is currently sitting. I stopped using Sparrow on my phone. Mostly because I hate Boxcar. I would definitely give Sparrow another try (once push gets implemented). I used the Gmail app for a few months while I was in London, probably 2 years ago now. It was ok. The two glaring issues I had with it were its lack of multiple account support, and it’s lack of native push support. Now that it has push, I’m giving it another shot in my workflow. What I’ve done is disable Mail in the native iOS mail client for my primary email address. I’ve then configured the gmail app to support that address. Basically, i get the Gmail interface for MY mail account, while my other accounts still sit in Mail. So far (ie: about 45 minutes) it seems like a viable solution. The plan is to try and get by for a week using the gmail app in place of Mail for my primary...
by Alex Holt | May 28, 2012 | Mobile, UI/UX |
So, a few weeks ago I came across Snapguide. It’s a great howto and guide app for iOS. The thing that really struck me about this app is how well thought out the interface is. iOS is a great platform for building apps to consume content, however content creation is somewhat limited. The only apps that really do a good job of content creation are simple, one step creation apps (like: Instragram, Facebook etc). Where you only create one piece of content, and you provide minimal information. Snapguide, on the other hand, has an inbuilt editor that allows you to create detailed photographic guides, all from the “comfort” of your iphone. The app basically asks its user to take photos of each step of a process and annotate them. It then joins these steps together to make a beautiful guide. The true interface magic is in the creation process. It actually makes it simple enough to take each photo, annotate it and add it to your guide. Also allowing you to re-order the photos and edit the guide (before AND after publishing). In testing the app, I created this guide (which went to their homepage features for a few days – and got a fair few likes as well): Make Paleo Tabouli. On a side note: i would highly recommend trying this recipe if you like tabouli.....
by Alex Holt | May 25, 2012 | Dev, Rants, Web |
So, this week I’ve been teaching web design at Shillington College in Sydney. Today we had an interesting discussion about <section> vs <div> for marking up regions on a page in HTML5 – in our case: particularly the main content region (which previously we style as <div id=”content”>. The debate stemmed from the (somewhat obsessive) idea that <div>’s are evil. The evil part of the <div> tag has more to do with the sloppy, messy usage that has become rife with the advent of WYSIWYG software that invariably writes terrible HTML. What people seem to not understand – or be reluctant to accept is that <div> is still a perfectly acceptable element in HTML5. Furthermore, I would suggest that there is no more semantic meaning in the use of <section> than <div>. As far as I see it, neither of them carries any intrinsic meaning. The other new HTML5 elements all have embedded meaning.. but section is really no more meaningful than <div> or <span> or any of our other un-semantic tags. The issue here stems from the seemingly conflicting messaging in the spec. on one hand we are being told to avoid the <div> tag, while on the other hand we are told to use it instead of section to markup a region: Note: The section element is not a generic container element. When an element is needed for styling purposes or as a convenience for scripting, authors are encouraged to use the div element instead. A general rule is that the section element is appropriate only if the element’s contents would be listed explicitly in the document’s outline So, while I understand the...
by Alex Holt | Jan 3, 2012 | Web |
I often harp on about how responsive web design is MORE than just adaptive CSS layouts. I believe that we should be building websites that contextually respond to the device/screen size in question. How does this apply to microcopy? Now, this is not a new concept, however it is necessary to articulate it in order to understand what i’m on about when i talk about responsive microcopy (microcopy being the small bits of fluff copy on the site that help guide the user and introduce areas). While building the latest iteration of my personal site, I wanted to write some friendly, conversational microcopy that would help guide the user around the site. However the design is completely responsive, and i found that the microcopy became waaay too long winded on small screens (read: mobile). SO I came up with a simple set of responsive CSS classes that would hide and show content based on my responsive stylesheets. So in my base CSS I have: .show600, .show768, .show992, .show1382 { display: none; } And then, in each respective responsive stylesheet i have a declaration that will make these elements display again. 600.css: .show600 { display: inherit; } So, when the user’s browser is over 600pixels high, my responsive CSS kicks in and this element is displayed. To use it i have HTML like this: <h4>This is some microcopy. It's really interesting<span class="show768">, however the user on a mobile might <span class="show992">find most </span>of it annoying</span>.</h4> So now the copy will render on browsers smaller than 768 like this: This is some microcopy. It’s really interesting. But once the browser spans more than 768 we get the...
