I'm working on the 'desktop' views of a web-app project that has a very complex set of potential filter criteria – it has upwards of 15 different filter groups or types of data that can be filtered on, with little available knowledge as to which filters are more or less important in each scenario.
To make things more interesting, each filter group has the potential to have multiple selections. We are also locked in to showing the filtering UI in a primarily horizontal format above the results table – using a sidebar was ruled out for other reasons.
Today, we tried to tackle the problem of how to display the selected filters.
There are a ton of ideas, however a quick sketch of the one that I ended up favoring is pictured above. We plot the filter group in a horizontal list. When the user clicks on a filter and makes a selection (these are dropdown/selects), the selected criteria is vertically listed below the criteria and is removed from the list.
The benefit is the user can see at a glance which filter criteria are affecting search results without having to add any further UI to draw the connection between the selected filter criteria and the filter group/category it belongs to. The connection is made spatially using the Y axis.
One weakness is the potential vertical height this will introduce, however there are many ways to address this, as well. Perhaps a 'show [x] more' link after a preset number of criteria.
Overall, I would prefer to use a more traditional faceted search/filter UI in a columnar sidebar format, but I thought this was a nice way to solve the problem, within the given constraints.
First the article from the guys at Intercom, now this from Benedict Evans.
I'm working on a responsive web app project myself, where I'm thinking a lot about atomized content being expressed in the card UI metaphor throughout the app. It seems very useful and promising for cross-device use.
Although a tablet seems big compared to a phone, it’s still a small screen and typically shouldn’t be subdivided into smaller frames or split views, except when users really need to access two types of information simultaneously. Every time you split off part of the screen, less remains to show content.
Jakob Nielsen recently published the above linked report on tablet usability1, and the linked summary presents its conclusions without having to pay for the full thing.
Nielsen's thoughts on tablets as small screens remind me how tempting it is, as a web designer, to view tablet screens as peers of typical laptop/desktop screens. After all most tablets have at least a 1024x768 resolution, and designers who think in terms of viewport sizes, commonly consider 960px or so as a typical 'desktop' viewport width.
However, what's missing with that logic is taking into consideration the physical size of the device. Tablets usually sacrifice several inches of physical screen real estate in comparison with laptops. This usually makes the tablet display sharper, but it also means that things appear smaller to a reader on a tablet than they would at the same resolution on a larger device.
This is beginner stuff, but it's often forgotten, especially when dealing with responsive websites. Often we are more concerned with the UI change from 'desktop' to 'mobile' (I like the term 'handheld' a little more). While really small screens often need more drastic changes, let's not forget about also optimizing for tablet readers.
I think Nielsen tends to be somewhat dogmatic and in this case, I think it truly depends on the content in question as to whether a subdivided or split view might be appropriate. Generally, though, doing one thing well is more and more important the smaller the screen gets. ↩
Designing static, linked web pages is a dying profession. The incredible rise of mobile technologies, APIs, SDKs, and open partnerships between platforms and products paints a crystal clear picture of a future where we will all design systems.
As I read this essay, I kept thinking – finally someone has crystallized why I feel like something 'other' in relation to some of my visual design friends. The rush to focus on pixels first in a new project is a symptom that the system design has not been properly considered.
How does this affect the tools and deliverables we should embrace?
PDFs full of wireframes are a dying deliverable, Photoshop is a dying product design tool. Designers moving our craft forward are moving between sketches, whiteboards and prototyping tools (Quartz Composer, After Effects, Keynote, CSS/HTML).
Being a designer encompasses a lot more than pushing pixels.
Starting from the left… Sparrow
The primary mail app I use on both my Mac and on my iPhone.
Hazel
It's my digital Roomba! Automatically cleans folders (such as your overstuffed Desktop and Downloads folders) based on rules you choose. Tons of hooks to customize exactly what you need.
Fantastical
Awesome little app that gives me pretty a full-featured Calendar complement right from the menubar. It uses natural language input and does a fair job at parsing values into fields such as even location, start and end dates, start and end times and invitees. I've had minor quibbles at times with how it works with Exchange mail, but overall it's quite solid.
Codekit
If you're a front-end web developer who uses CSS preprocessors such as SASS or LESS, this is for you. Set watch folders to automatically compile your LESS files, minify your JS and optimize images, as well as a range of other automagical stuff.
Slingshot
I must use this app about 30 times a day. Here's what it does: Click the menubar icon, choose Capture Screenshot, then draw out a rectangle on your desktop. It automatically saves the screenshot as a PNG, saves it to a preset destination in Dropbox (or Imgur, up to you) and populates your clipboard with the publicly sharable link. Yes, a ton of other apps do almost the same thing, but this one does it the best, as far as I'm concerned.
Dropbox
Essential. Enough said. I pretty much use this as my cloud drive for all my documents.
CloudApp
This one is similar to Dropbox and Slingshot, except it works slightly differently. With CloudApp, I can drag a file or group of files to the menubar icon, at which point it starts uploading the files to the service. The cloud icon acts as a progress indicator and a bell rings when the upload is done. At that point, you again get a publicly sharable link that populate your clipboard. CloudApp also has a companion iOS app to access uploaded files. It's the easiest way to quickly share a file with someone that's NOT a screenshot.
Transmit
My FTP editor of choice, by the fine folks at Panic. Despite minor quibbles, I wholeheartedly recommend it over any other OS X FTP client.
Tunnelblick
I frequently need to use a VPN, and Tunnelblick is the best OpenVPN GUI I've found for OS X.
A very convincing showcase of the best that Google Web Fonts has to offer. Yes, Google Web Fonts has a ton of crappy fonts available, but this site will help you see through the debris and find the gems.
A website and app that acts as a collective gallery for typography specimens found in the wild. Categorized by industry1, format, and typeface. Recently they've added the ability to create your own custom collections as well as upload your own specimens.
A jQuery plugin by the nice guys at Paravel. FitText makes font-sizes flexible. It is especially useful when attempting a fluid or responsive layout. It enables you to achieve scalable headlines that fill the width of a parent element. I used it recently on a project that will be released soon.
I wish more web design galleries were more industry focused. I tire of seeing galleries all stuffed full of portfolio sites. ↩
I think an even better solution would be to remove the password completely, allowing users to login with only an email address. Each time a user needs to login, they enter their email address and receive a login link via email.
Interesting solution by Ben Brown to the problems with traditional log-in system for web applications. Essentially, the flow would go like this:
The Mac App Store is in significant danger of becoming an irrelevant, low-traffic flea market where buyers rarely venture for serious purchases. And I bet that’s not what Apple had in mind at all.
I agree with Marco that the way the sandboxing rules are implemented seems to be doing much more harm than good to Apple, Mac developers and Mac users. I think he's especially right about the potential effects on iCloud adoption:
This even may reduce the long-term success of iCloud and the platform lock-in it could bring for Apple. Only App Store apps can use iCloud, but many Mac developers can’t or won’t use it because of the App Store’s political instability.
Personally, I think iCloud is a confusing mess. Laudable in its aims, but shoddy in its implementation. Apple has traded one problem (the average person's perceived lack of comfort with the file system) for another (a system where there is no canonical location the user can access).
