Tools

Desert Island Apps

| Jorge Arango

I’m always looking for ways of optimizing my personal information ecosystem. By this, I mean focusing on the work rather than futzing with the environment where the work happens. Ideally, I’d log into my computer, do a bunch of work, and then log out without having to think too much about the tools I’m using or how I’m using them.

The challenge is that digital tools are constantly evolving. There may be a new app out there that eases a part of my workflow, or perhaps one of the tools I’m already using has a hidden feature I’m not using. Sometimes such innovations can lead to tremendous efficiency gains, so it’s important to step back and review the ecosystem every once in a while. It’s a tradeoff between spending time working on the work versus on the way we work. A subtle, but important distinction.

Earlier in my career, I devoted a higher percentage of my time to working on my ecosystem than I do now. My toolset has been relatively stable for a long time. In part, this is because I eventually realized that many “new and improved” digital tools are specialized adaptations of more general, deeper tools.

For example, when my family and I were preparing to move to the U.S., I bought an app that allowed me to catalog my book library. I spent quite a bit of time messing around with that app. Eventually, I realized it was actually a specialized spreadsheet — something that’s also true of many lightweight data management apps. Rather than spending time learning a new app that perhaps adds a couple of timesaving features (in the case of the library app, it was reading ISDN codes), I could devote the time instead to figuring out how to do what I needed with the tool I already had: Excel.

Excel is an example of what I call a “desert island” app. Like the concept of desert island books (i.e., the short list of books you’d like in your bag if you were to be stranded in a desert island), these are digital tools that I could use to get my work done even if I had access to nothing else. They tend to be deep and broad, have large and devoted communities of users, and have been around for a long time. Other tools that fall into that category for me are the Emacs text editor, the Unix shell (along with its suite of “small pieces loosely joined” mini-tools), OmniGraffle for diagramming, and Tinderbox for making sense of messes.

Editing my newsletter in Emacs.
Editing my newsletter in Emacs.

These are all tools I’ve used for over a decade. (In the case of Excel, Emacs, and the Unix shell, over two decades.) But even after all this time, I’m nowhere near mastering them. My relationship with these desert island apps is a lifelong journey in which I will continually become more proficient — which will, in turn, make me more efficient. I test drive new apps now and then, but I always return to these old standbys. The effort of learning to use them in new ways is often less than that required by integrating new tools into my workflow.

What about you? Do you have “desert island apps”? Please do let me know — I’m interested in learning about what makes digital systems stand the test of time.

Trading Off Freedom for Convenience

| Jorge Arango

Google Docs is notifying users of the new Microsoft Edge web browser that their browser is unsupported. It’s surprising, given that Edge uses the same rendering engine as Google’s own browser, Chrome. I don’t know if there’s anything nefarious going on (i.e., Google trying to stifle competition in the browser space), but I was reminded of all the trouble I’ve been having lately with my preferred browser (Safari).

To recap: Chrome’s dominance in the market is now large enough that many web app developers target it by default, often at the expense of less popular browsers like Safari. One side effect of this is that some apps don’t work — or don’t work as well — with Safari. The situation has gotten worse since I wrote my previous post on the matter a little over a month ago. More and more major apps are failing for me in Safari, while Chrome gives me no such trouble. This includes systems that are key to my business, such as Quickbooks, Webex, and one of my banks’ websites.

These are systems I interact with on a daily basis. As a result, I now keep Chrome open all the time alongside Safari. I don’t like this situation, for the practical reasons I documented in the previous post. But more philosophically, I don’t like it because it’s a constraint on my freedom to determine the components of my information ecosystem.

The foundational components of my ecosystem are:

  • its operating systems (macOS and iOS),
  • file managers (Finder.app and terminal shell),
  • web browsers,
  • text editors.

I could get much of my work done with just these components. There are other specialized apps in the ecosystem (spreadsheets, diagramming software) that are very important to me, but not to the degree a text editor or a web browser are. (I can access spreadsheet applications using a web browser.) Being forced to replace one of my preferred options for these central components rubs me the wrong way.

Software organizations like Google want us to be all-in on their information ecosystems. I see this goal as being in tension with my wish to define and control my personal information ecosystem. Google’s ecosystem has a lot of neat features — especially if you must collaborate with other folks. (Something I do a lot.) One easy way out for me would be to acknowledge the reality of my current needs and switch over to Chrome. This would certainly be more convenient for me. But convenience often comes at the expense of freedom.

There was a time in my life when I used a lot of open source software: My PC ran on Linux; Firefox was my browser of choice; I worked mostly using Emacs and a host of *nix command-line tools. I had a great deal of freedom. I could even tweak the kernel of my operating system! But I also spent a lot of time maintaining this ecosystem. Every (seemingly) minor tweak required hours of Googling. And all of these tools were “behind the curve” technologically; the more commercial ecosystems had more and better features. I spent almost as much time trying to find workarounds as I did trying to work.

Eventually, I gave up on the whole open source thing and moved back to the Mac (this was at the beginning of the OS X era.) Mac OS was much more convenient than Linux, but it was also more limiting. That was part of its appeal. I also held on to some aspects of it (Firefox, Emacs) which were also present on the Mac. I was excited to switch from Linux to Mac OS, and undertook it with full awareness of the tradeoffs it required.

I’m reminded of this transition as I contemplate how to approach my web browser woes. I’m not excited about having to switch over to the monoculture du jour for the sake of convenience. This time, I’m also aware of the tradeoffs required this time around — and I’m not happy about it.

Direction and Action

| Jorge Arango

Invariably, the most popular posts on this site are the ones that deal with tools and practices. Whether I’m railing against wireframes or showing you a way to make language visible, if it features a concrete tool or technique, the post is likely to have traction. This doesn’t surprise me.

My tool-centric writings fall on the craft end of the craft ↔ philosophy continuum. Philosophy is a harder “sell” than craft. Most people would rather know what to do rather than how to think; they want things they can put in practice on the proverbial “next Monday morning.” The more actionable something is, the better.

Except that action can be undirected. And effecting action towards the opposite of “Good” (perhaps unintentionally) makes things worse. Direction without action frustrates; action without direction muddles.

I don’t aspire to give direction in my more “philosophical” writings. Instead, I’d like you to entertain the possibility that direction matters, and that you ought to discover one for yourself. The world provides ample evidence of things that are going well and things that could be better; it’s up to you to determine what those are and what you can do about them.

Against Wireframes

| Jorge Arango

Yesterday I led a bright and engaged group of folks through my Information Architecture Essentials workshop. Most of them were new to the discipline, and wanting to know more. We talked about many things, but had an especially active discussion about wireframes. I don’t like them and haven’t used them in my work for a long time. I thought it worthwhile to document my reasons here, in case it helps anyone.

Wireframes are a design artifact that has long been associated with information architecture. I’ve heard people ask to be “sent the IA” meaning they expect something that looks either like a sitemap and/or a set of wireframes. I consider these “deliverables” to be tools from a prior — more “waterfall” — era of web design and mostly a waste of time today, if not outright misleading. (I include sitemaps in this statement, even though I’m focusing on wireframes here.)

Although I’m sure it’s been written about at length (and better) elsewhere, here are some reasons why I don’t like them:

  • Wireframes are too abstract and not abstract enough. Wireframes are an attempt to explore the relationships between elements in a screen. Often this includes the relative visual priority of things. However, they attempt to extract aesthetics (the “visual design”) from these visual explorations. As a result,
  • Wireframes confuse stakeholders. I think of design artifacts as tools that allow people — both designers and stakeholders — to make design decisions. Wireframes are mostly clear to designers, but not to stakeholders. Asking folks to comment on the relative hierarchy of elements in a visual document while also asking them to ignore the aesthetics of the thing is a tall order.
  • Wireframes are ineffective as decision-making tools. Visual design affects the perception of the relationship of elements on the screen. Font and color choices affect the relative prominence of elements. More abstract wireframes fail to convey these important distinctions. On the flip side, less abstract wireframes are close enough to visual design to derail the conversation towards the lack of aesthetic nuance. As a result, wireframes are seldom effective in helping people make design decisions.
  • “But,” you may protest, “we don’t use wireframes to make decisions. We use them to convey decisions to developers.” Alas, wireframes are also ineffective as design documentation. Wireframes require more effort to produce and maintain than lower fidelity artifacts (like freehand sketches.) Evolution of the design seldom stops when the wireframe deck is complete, leading to either the deck becoming outdated or — worse — design being “fixed” because the wireframe deck is now “signed off.”
  • Wireframes give the impression that things are more polished than they are. I’ve seen designers present early-stage ideas as wireframes. (Perhaps because some folks are uncomfortable drawing freehand?) These artifacts can look very clean and beautiful, leading the viewer to assume that the ideas they present have been thought-through. Often they haven’t.
  • Wireframes are relatively expensive to produce. Given that so many organizations are using design systems these days, building a comp using a tool such as Sketch isn’t that much more work than making a more abstract artifact such as a wireframe.

So what’s a better way of doing it? I prefer freehand drawings, which allow designers to vary the fidelity of artifacts on the fly. Nobody confuses a freehand drawing with a more polished artifact. Freehand drawings are fast, cheap, and disposable; if somebody has a great new idea, you can draw it on the spot. Yes, this requires that designers learn to draw. (I’m still astonished that some people protest this; communicating visually is essential to design work.)

My preferred way of sketching freehand is to use the Concepts app on the iPad Pro. This app treats the lines I draw on the screen as vector-based “ink”; I can select sets of lines and copy them, paste them, delete them, stretch them, mirror them, etc. This allows me to reuse elements (such as window chrome) across drawings, speeding up the process tremendously. Concepts also allows me to share drawings directly to Slack, email, or other channels. The result: very tight feedback loops that enable the design process to move much faster.

What if you’re communicating design intent to developers? In that case, comps or prototypes do a better job than wireframes. It’s not unusual for developers to ask to be sent Sketch files so they can pull out things like colors and element sizes.

Of course, there may be exceptions to all of this. Some teams may have particular circumstances that allow them to move fast using wireframes. Some industries may require them as official documentation. But in my experience, they aren’t very effective. If you’re a stakeholder, don’t waste time and money by asking your designers to create wireframes. And if you’re a designer, learn the basic principles of drawing by hand (such as the use of distinct line weights, how to start and end lines, etc.) You’ll get better results faster.

How to Understand a Complex Subject

| Jorge Arango

Sometimes you need to understand a complex subject. When first getting into it, you’re faced lots of new concepts and ideas, unfamiliar language, unexpected connections between terms, etc. There’s lots of information to digest. Where do you start? How do you make sense of it all?

Understanding complex subjects is a meta-skill: a skill that helps you become better at acquiring other skills. When you hone your ability to understand, learning new things becomes easier. Improving your sense-making skills is a powerful boost for your effectiveness.

Concept mapping is the best practice I’ve found for making sense of complex subjects. A concept map is a visual representation of the relationships between concepts that affect a particular problem or domain. In contrast to a linear exposition of the subject, a concept map lets you pick the starting point for your investigation and allows you to see details in the context of the big picture. A well-crafted map achieves the goal Richard Saul Wurman laid out for information architects: to help others find their own paths to knowledge.

The best conceptual mapper I know is Hugh Dubberly. The Dubberly Design Office website has an entire section dedicated to showcasing their beautiful and insightful maps. These maps are inspiring — and also a bit intimidating. But concept maps mustn’t be elaborate or polished to be valuable.

A post on the DDO blog shows you how to create your own concept maps. I use this approach with my students and in my professional work; it’s the best way I’ve found to understand complex subjects.

Managing Screen Time

| Jorge Arango

One of the best features of the most recent version of iOS is called Screen Time. It allows you to monitor and control what you do with your mobile devices and when. For example, you can find out how much time you’re spending on social media apps and whether your usage is increasing or decreasing. You can also set limits for yourself on the device overall or on a per-app basis. And if you use multiple iOS devices (such as an iPad and an iPhone) you can configure Screen Time to show you your behavior across all of them.

To access Screen Time, you must open the device’s Settings app. (This feels a bit incongruous. Although I understand this is an OS-level feature, it feels like something that should be independent of Settings. Anyways, I digress.) In the Settings app you’ll see an option for Screen Time:

If you tap on this menu item, you’ll be shown a screen that looks like this:

Continue reading →

A Stowable TV

| Jorge Arango

Managing kids’ screen time is a challenge. My wife and I cut the cable close to 7 years ago, so my children haven’t grown up in a traditional (read: advertising-supported) TV household. While we still owned a television, our screen time has been much more intentional.The last time we moved, we took an even bolder step: We got rid of the television altogether. In its stead, we bought an LCD projector and a soundbar. During the school year, we keep the projector stowed during most of the week. We bring it out Friday evenings for family movie nights, which happen every weekend evening unless we have other plans. The projector goes back into storage on Monday mornings. (The soundbar remains in the living room; it doubles as our sound system using Airplay.)

This approach has turned what would’ve previously been an individual attention suck into a family event we can all enjoy together. It satisfies the need for the kids to be into media without becoming beholden to the tube. (At least until they’re old enough to demand their own smartphones. Alas, the rumblings have already started in my household.)

In Praise of Email, Which I Want Less Of

| Jorge Arango

For many people today, most work happens in information environments. Much of it consists of collaborating on and coordinating activities. In other words, it requires communicating with other people. There are various ways for people to communicate in information environments. Email is one of the oldest. It’s also one of the best.

You can set communications channels on a continuum based on latency. On one end of this continuum, you have face-to-face communication, which is very low-latency. When somebody says something to you in your presence, you get what they’re saying almost as soon as the words leave their mouth. In many cases, there’s also a social expectation that you will reply right then and there. Long pauses can be awkward; you must respond even if it is to say, “I need a minute.” Face-to-face oral communication is what we call a synchronous channel — the back-and-forth between participants happens in “real time.”

On the other end of the continuum are communications channels that don’t carry such expectations, mostly for technical reasons. For example, if you send a question on a (physical) postcard to your friend halfway around the world, you know that the piece of cardboard that conveys your question will take some time to get to where your friend is. Your friend might read your message a few days from now. If she chooses to respond with a postcard of her own, it too will take several days to reach you. Considerable time will elapse between the time when you issued your question and when you got a reply. Thus, postal mail is what we call an asynchronous communication channel.

Continue reading →

An Example of a Semantic Environment Map

| Jorge Arango

I’ve had folks ask me for examples of a semantic environment map. Here’s one for the confessional, a semantic environment within the broader environment of the Catholic Church:

Did I get it wrong? It’s likely. If you can spot problems, the map is serving its purpose: to help us have discussions about contextual issues that often go unnoticed or unexpressed.

If you want to create a map of your own, you can download a PDF of the Semantic Environment Canvas.