“The manner in which he calls on the audience to participate is telling, too. He wasn't the star; the audience was. Music was a vehicle for mass expression. That helps to explain his opposition to Dylan's new course. Confronted with a rock band, the audience were reduced to mere spectators, fans; Seeger wanted participants, activists, He wanted to change the world, not just entertain it.”

Sorry for the off-topic post. But there’s lessons in here for software as well… (I’m enjoying the 1963 concert recording a lot, by the way.)

“One of the things I always think about is how to deliver three things to everyone that works for me. One is autonomy, one is mastery and one is purpose.”

These three (taken from Dan Pink’s “Drive” book) are exactly what I value and want the most as an employee. Here’s what they mean to me:

Autonomy means that we can take initiative, make decisions, take responsibility, and manage our work on our own. We can only have autonomy if management trusts us to be self-motivating grown-ups, experts who work in the best interest of the company and its customers (even when no-one is supervising us). It also requires transparency and full information sharing – if someone holds back information, he’s keeping us from making the right decisions.

Mastery is two things: First, we want to be able to do great work – we love to learn, to get trained and gain experience. But then, we also want to be allowed to do great work. Stop the mediocrity, the permanent rushing and cutting corners, the overpromising and underdelivering. We want quality and beauty and excellence. Not to selfishly enjoy our pretty code, but for the long-term good of the customer and the company. (Be aware that we keep growing: While you might think we’ve just mastered some programming language, we’ve learned a lot more in the process and strive for quality in every other aspect as well.)

Purpose feels different for everyone, I guess. My goal is to make people happy by building tools that make their jobs easier and more fun. Tools that facilitate knowledge sharing, learning and creativity, which in turn will positively affect even more people. (Building photo databases and newspaper archives, as I’m currently doing, is a pretty good match.)

Want to keep your employees happy and motivated? Money can’t buy you that. Be willing to lose power, to truly care for them and treat them as partners. And give them autonomy, mastery and purpose.

We’re still discussing the main navigation of our simple DAM UI. The first draft of the navigation looks okay to us, but the dropdown to the left of the search box might not be noticed by everyone.

Our friends and customers at Bauer Media recommended that we add a list of asset types (Articles, Images, Pages, more…) between search form and search result. This would be easy to spot and require just one click to repeat the current search in a different asset “pool”.

Taking this one step further, the asset types are not the only way of filtering search results. In the current UI, DC-X offers four (configurable) metadata fields to filter on. That many filter options take a lot of screen space: Other Web sites often move them into a left column, and that’s what we’ve done in the current draft (see the screenshot above). Search results have a narrow column on the left side with filter options, including asset types (or more generic, “channels” in DC-X terms). The dropdown in the header can still be used (from any page) to jump to a certain section of the site.

We also removed the second search input field, which looked a bit confusing (but had the advantage of being larger than the small text field we’re able to cram into the header). If this approach works out, there’s no need for a separate “search form”; we’ve got the fulltext search field in the header and all other search restrictions in the left column.

“I’m also a very strong introvert. I recharge when I’m alone or in very small groups of people (no more than 2 including myself is ideal) and I exhaust myself in crowds or in constant discussion.

[…] The reason crowds of people exhaust me is that I am constantly trying to read and understand the feelings and motivations of those around me. If I could just go through life talking and not listening, hearing but not processing, alone time and time in groups wouldn’t be so different for me.”

Searching, and browsing result pages, is at the core of Digital Asset Management systems. Our current software uses pagination when presenting results, i.e. you start at “page 1” and click through a set of numbered pages. That’s what Google and Bing Web search, eBay, Amazon and many more are doing.

“Infinite scrolling” is the shiny new alternative: You stay on a single result page – an inifinite stream that automatically (or sometimes, manually) loads more items as you scroll down to the bottom. See Google image search, Facebook or Twitter.

Make sure to read Anthony T’s in-depth discussion Avoid the Pains of Pagination: “It’s important to have [pagination] on your site to prevent your pages from becoming too long and overwhelming. […] Users have better experiences with scrolling than clicking. The mouse wheels, touchpads and touchscreens of today make scrolling faster and easier than clicking. […] Infinite scrolling can frustrate users. When the user clicks to go back, they’ll lose their place and progress in the content stream and will have to scroll from the top of the page again.”

Tony Russell-Rose writes in Designing Search (part 6): Interacting with results: “While infinite scroll offers a more seamless experience (minimizing disruptive page reloads), and forms a natural expression of the fluid interactivity of smartphones and tablet displays, it does have a number of drawbacks. First, it is much harder for the user to determine precisely where they are in the result set or to navigate to a particular section. Second, it is no longer possible to bookmark an individual page of results.”

In the long term, it’s about making things simple for users. We don’t really know yet what works best for them. (We’ve been asked a few times to switch to infinite scrolling, but usually by techies, not “end users”.) My working hypothesis is that they’re most likely to be familiar with Google and Amazon pagination. Also, it’s not unusual to hear them refer to a page number (“that image on the second page”) or see them browse through thousands of results (which doesn’t work too well with infinite scrolling).

But in the short term, we must also make features simple to develop. Overcomplicating things keeps us from releasing our software, and from getting feedback from our customers. That’s why we’ll probably skip infinite scrolling for now: Pagination is a whole lot easier to implement and much less fragile and error prone.

What’s your opinion on pagination versus infinite scrolling?

Update: Hoa Loranger writes for the Nielsen Norman Group in Infinite Scrolling Is Not for Every Website: “Long, endless pages are good for time-killing activities because users are in the mindset for serendipitous exploration and discovery. […] It’s much easier for people to remember that the item is on page 3 than it is to gauge where the item is positioned on an extremely long page. […] With pagination […] there is a happy sense of completion when a page is reviewed. […] The choices on smaller pages are easier to evaluate because fewer options feel less overwhelming.”

Update (2017-04-19): Nick Babich – UX: Infinite Scrolling vs. Pagination: “There are only a few instances where infinite scrolling is effective. It’s best suited for sites and apps that boast user-generated content (Twitter, Facebook) or visual content (Pinterest, Instagram). Pagination, on the other hand, is a safe option, and good solution for sites and apps that intend to satisfy the goal-oriented activities of the users.”

Getting a Web application’s navigation right is hard. Space and user attention are limited, users have different needs and ways of working with the app, and the content is also different from customer to customer: Some have a wide variety of digital asset types and usage scenarios.

Our simpler DAM system UI will allow for customization of the navigation, but we still need to decide on a sensible default. The screenshot above shows the current state of the discussion, a first draft that’s going to be discussed with potential users.

In this draft, the only constant navigation element is a menu bar at the top of each page. (We had an additional sidebar on the left side of each page, but left it out for now to keep things simple and reserve this space for filters in search results.)

The items in the menu bar are (sorry for the German screenshot):

1. A logo and application name (both customizable) that link to the home page.

2. A search element that consists of the category/search scope, the search input field and button. Clicking the category displays a mega drop-down where you choose a channel, stored search, or collection (tag) to search in. You’re immediately taken to the search result page of the channel you click there, so this also serves as a navigation aid when you want to browse without entering a search term.

3. A link to the history page. To save space (and because it’s a bit less important), this link has no label. The history page lists your recent searches, documents and collections you viewed and the actions you performed on them.

4. A link to the “clipboard” page. The clipboard is a special, pre-defined collection that you can add documents to with just one click – to revisit and act on them later. Its contents are archived nightly so that you start with a fresh, empty clipboard each morning. But you can still access the last 7 day’s archived clipboards.

5. Links for file upload/ingestion and article creation (since DC-X is not only good for file-based assets, but for textual content as well).

6. A popup menu for user settings and logging out.

It’ll be fun to compare this rough draft to the final product in a few months :-)

Our Digital Asset Management system DC-X has a Web based user interface (UI) that has been built primarily for power users: Lots of functionality and information, keyboard shortcuts, drag & drop, right-click context menus, small fonts, slow load/startup (single page Ajax Web app), large screen required. The first impression can be a bit intimidating, but with a little bit of training most people seem to be okay with it.

Still, our customers keep asking for something that’s much simpler to use: A self-explanatory UI to save training time and costs, and to increase acceptance and adoption of the DAM system within their companies. And they want it to look more attractive and run on tablet and smartphone browsers, too.

(Compare the screen shots above: Both show a search result with images you can click on to see details. In the current, complex UI to the right, there’s an additional 101 things you can click on. In the simple UI prototype to the left, there’s only 24 additional click targets…)

That’s why we’re (finally) starting to develop a second user interface for DC-X. It won’t replace the current UI – power users will continue to use that one. But the new one (working title: “Simple UI”) is supposed to become the better choice for regular users, making it way easier to use the basic DC-X DAM features (search, read, download, share, upload new files, create and edit articles).

I’ll post a few articles during the next weeks regarding the decisions we have to make while building a new UI. And I’d love to get your feedback!

One of the more technical decisions when building our simpler DAM system user interface: Should we build it like a Web site, i.e. as a set of interlinked but independent Web pages? Or as a fancy, Ajax-powered “single page Web application” that you load just once, with all further interactions taking place within the same page?

The last times we had to decide this, we went with what was fashionable: DC4 lived on a single page that consisted of various frames. DC5 was a Web site with different pages. The current DC-X UI is a single page app (SPA).

Pros of an SPA: Faster and smoother, no need to wait for a full page reload (and JavaScript, CSS, HTML don’t have to be parsed again). State (like “menu bar expanded”) can be kept in local variables, no need to pass it between pages. You can push notifications onto the page, knowing that the user will spend some time there. Read: Matt Johnston – Let’s make a single page Web, or Steve Souders – Keys to a fast Web app. It’s also interesting how Twitter and Basecamp built their Web apps.

Cons: Way harder to develop. Takes longer to load initially. More fragile, possibly breaking on clients with little RAM or CPU power. Issues with links and browser back/forward buttons. SEO broken because search engines won’t run all your JavaScript. Read: Swizec Teller – Single page web apps: the worst of both worlds.

My take: It’s better to start with regular Web pages, because their development takes much less time (enabling an agile, incremental development process). Moving to a single page app later is totally possible (the other way round is way harder). And initial load time as well as working links are important for casual usage (they don’t have the DC-X UI open all day) and Web interoperability.

“There comes a time […] when it’s important to pause for a bit and look in rather than up. When it’s more important to improve existing features than to add new ones. More important to make our existing users happier than to just add more new users. […] Intentionally slowing down to focus on details and quality doesn’t come naturally to many of us. Despite this, the best product companies in the world have figured out how to make constant quality improvements part of their essential DNA. Apple and Google and Amazon and Facebook and Twitter and Tesla know how to do this. So will we.

[…] Since all Evernote employees are power users by definition, no one is more motivated to make Evernote better just for the sake of our own productivity and sanity. I’ve never seen people happier to just fix bugs.

[…] We understand that we have to maintain a high level of quality for the long term, if we want Evernote to be seen as a truly high-quality product.

[…] Our goal isn’t to have a product that’s just good enough that users rely on it despite its warts, it’s to have a world class product, built with solid technology and with a fit and finish worthy of our users’ love and loyalty.”

A great post, the likes of which I’d love to read from a lot more CEOs!