sketch

Sneak preview of the new Drupal UI for content creation

Roy — Sat, 10 Feb 2018 23:56:19 +0000

Sub title

No it isn’t. But maybe it should be.

/sites/default/files/styles/large/public/20180210-content-creation-ui-preview.png?itok=DbU7bNKf

I declared separate title and body fields old school in that previous post about removing friction. In the mean time, I’ve installed and tested a few Android applications for taking notes. There too it was an immediate turn-off to see a separate field for the note title. Let me write something first, I might think about naming it later. Often (in this note taking context) it’s not even really necessary. And so the first few words of the note becomes the title on the notes listing screen.

Even simply showing a label with, and a border around individual form fields is emphasizing the implementation model. Of course these elements are sometimes necessary affordances to show, but still:

Using the first line in a body of text as its title seems like a sensible default. No need to be so literal and explicit about it and present separate input boxes for both.

First things first

Roy — Mon, 08 Jan 2018 22:05:14 +0000

Sub title

Get a grip on the whole before diving into details

/sites/default/files/styles/large/public/20180108-first-things-first.png?itok=c6JIU2IX

The architect designing a house does not start with choosing and arranging the furniture in the living room. Even if the client really wants that one specific large corner couch.

No matter how custom the eventual design, for each house there’s some basics that need to be taken care of. A way to enter it, some holes in it to let sunlight in, dedicated spaces for cooking, sleeping, washing up, etc.

Any tool or app that is not super small can easily be as complex as building a house.

Establish foundations first

Don’t get lost arranging details on a single screen if you’re not yet clear of the fundamentals. How can you enter? How many different types of rooms do you need? How are they connected?

Individual screens are easy to create in isolation but if you start there, you’ll have a hard time arranging them into a coherent structure. At the same time you’ll likely need a home screen, listings, detail pages, forms and the like. Establish the main paths, flows, scenarios as guides for stringing those basic page types together.

Get a grip on the full set of things that your new design needs to accomplish. It’s easy to get lost in polishing the details of a particular screen component when working in high resolution tools like Sketch. First establish that you need a list of items on this given screen because of some search or navigation action on a previous screen. Only later figure out the specifics of what to show for each item in the list.

Sitemaps and flows before wireframes. Pen and paper before digital. Not having an undo is not a bug but a feature. Redo instead of undo to get a grip on the whole.

Some resources

Luke Wroblewski has an older talk about this: Parti & the design sandwich
Page description diagrams are an old school, more text based version for creating the big picture
Haven’t tried it but looks like Flowmap wants to provide that sweet spot between global (sitemap) and local (wireframes). (You should still start on paper though.)
Think of your app like a collection of hubs and spokes
You’ll probably need these types of pages

3 kids, 1 iphone

Roy — Mon, 31 Dec 2012 17:39:44 +0000

Old doodle card

Roy — Tue, 28 Aug 2012 20:41:38 +0000