Tools

TAOI: Reimagining Email

| Jorge Arango

The architecture of information:

The team at Basecamp has developed a new product, Hey. It seems like an interesting — and opinionated (I mean this in a good way) — reimagining of how email works. If you have some time, Basecamp CEO Jason Fried’s video introduction is worth your attention:

Hey was in the news yesterday because its mobile app is being pulled from Apple’s iOS App Store, and Basecamp’s management is vocally fighting the move. Much has been written about that situation already, and I won’t say more about it here. I say it “seems” interesting because I haven’t yet tried it firsthand; currently, access to the product is by-invitation. My thoughts below are based solely on the product’s website and the video above.

Continue reading →

Honing Our Remote Collaboration Abilities

| Jorge Arango

Most of my career, I’ve worked in a blend of physical and digital environments. While most of my “productive” time has been in front of screens — initially desktop computers, then laptops, and increasingly mobile devices — with few exceptions, I’ve worked with teams and clients I’ve met regularly in “real” spaces like offices and conference rooms.

My collaborators and I would check in on each other in these physical spaces every once in a while, and then go back online. Often, our bodies sat in the same building — which we’d spend much time moving to and from — even though most of our attention while there was focused on our individual computer screens.

That changed two weeks ago. Like many of you, I’m now entirely online — for work, at least. My schedule is still packed, but all meetings are now happening in screens. I only see my collaborators in grids of small rectangles arranged haphazardly in an application window. In one sense, we’re pros at it; we’ve been doing this for years, after all. But now that we have no choice, we’re becoming even more adept at new ways of collaborating remotely.

For example, this week, I learned that Zoom — the software I’ve been using for years for most of my remote meetings — offers breakout “rooms.” This feature allows participants in a conference call to break off from the main meeting into groups to have a smaller discussion or work out a gnarly problem. It’s a boon for remote workshop facilitation. How long has this feature been there? I don’t know, but I never needed to look for it. Now that circumstances have called for it, I’ve gained a new ability.

I expect to learn many other techniques to improve how I collaborate remotely before this unique period of working from home is over. I aim to emerge from this experience as an expert in remote facilitation and teaching. At first, I’ll be clumsy at it — but so is everyone else. I expect we’ll all be more patient with each other at this time, given we’re all trying to get over the awkwardness of being fully remote. But we’ve been granted the opportunity to practice remote collaboration intensely over the next few weeks, and our new abilities will expand the scope of who we can serve, and when.

Outlook Spaces

| Jorge Arango

Last week I was reminiscing about Microsoft Entourage, an old (and discontinued) Mac groupware app:

Entourage was Microsoft’s answer for Mac users who wanted Outlook. Like Outlook, Entourage allowed you to manage your calendar, contacts, tasks, and notes, alongside email. But it also included an interesting feature that wasn’t available in Outlook: the Project Center.

The Project Center allowed you to create focused views of your emails, appointments, tasks, notes, and files. It narrowed down the information in Entourage according to project-specific filters that you’d configure. I was running a design consultancy at the time, and Project Center made it easier for me to keep track of several projects simultaneously.

Entourage was replaced by a “proper” Mac version of MS Outlook in 2010. Alas, the Project Center didn’t make the cut. At that point I moved to Mac OS’s built in calendar, contacts, and mail apps, and haven’t looked back.

I’m bringing this up because a recent post on The Verge highlights a leaked upcoming feature for Outlook:

Microsoft is working on a new organizational feature for Outlook, named Spaces. Twitter user WalkingCat revealed the new tool in a leaked video over the weekend, and Outlook Spaces looks like it’s designed to allow users to collate emails, notes, files, documents, calendar appointments, and to-do lists into online spaces. It looks like it will be useful for students or businesses that are planning projects.

I don’t usually point to posts about unreleased products, but am making an exception for this one because of two reasons. First, I have a soft spot for placemaking metaphors in software design. The name of this feature (“Spaces”) is clearly such a metaphor. Second, Outlook Spaces sounds a lot like Entourage’s Project Center — but smarter.

Project Center had a lot of promise in theory. In practice, it was a slog. The problem was that the system required a lot of maintenance. The search filters for each project had to be adjusted often; if a team member joined or left the project, you had to re-configure the filters. You also had to manually tag emails, notes, tasks, and events. So while the system would indeed focus your information, it wasn’t very smart: you had to work at it, not just in it.

Outlook Spaces may solve this problem. The leaked description highlighted on The Verge suggests upcoming releases may use AI to automatically discover and group information. This would make using such a system much more practical, since it wouldn’t require as much maintenance. (Of course, this is assuming that the AI works properly.) The possibilities are exciting.

Still, such a system may not work for me in 2020. Twelve years ago, I communicated mostly through email, so Entourage was a nexus for my work life. These days, my communications are spread over a variety of systems: email, Slack, Messages.app, Twitter, LinkedIn, etc. This makes it much more difficult to centralize communications, and a system like this one would have to include everything to be useful.

As a result, I suspect that Outlook Spaces would be most useful for organizations that are all-in on Microsoft’s ecosystem. That’s unlikely to be my case anytime soon. That said, I’m excited by the prospect of such at tool using modern technologies.

Leaked video reveals Microsoft’s new Outlook ‘Spaces’ feature

Alternatives to 32-bit Apps on macOS Catalina

| Jorge Arango

When a new version of macOS comes out, I usually upgrade my computer relatively soon. I like having access to the latest features, and significant macOS release upgrades are generally trouble-free. That hasn’t been the case with the newest version, Catalina. The trouble stems from the fact that Catalina doesn’t run 32-bit applications. While most major software in the system is now 64-bits, there are still some stragglers — especially legacy apps and drivers that haven’t been (and likely won’t be) upgraded.

That’s why I waited longer than usual before upgrading to Catalina: there was one application in my system that was 32-bits, the driver for my Fujitsu ScanSnap S300M scanner. I knew this driver was incompatible because every time I launched it (under Mojave, the previous version of macOS), I’d get a warning saying that the app would not run in the future. (Here’s a way to learn which apps won’t work: under the Apple menu, go to About this Mac > System Report… > Legacy Software.)

Without this driver, the scanner is useless — even though the hardware is perfectly functional. This device is an important part of my workflow; I use it every other week to digitize most of my paper documents and correspondence. Fujitsu no longer sells this model and has no plans to release 64-bit drivers. So I was stuck. I had two choices: I could hold off on upgrading the operating system (for a while), or I could buy a new scanner. I didn’t like either option. Sooner or later, I’d have to upgrade the OS. And as I said, the scanner itself was in perfect condition; I didn’t need a new one. What to do?

It turns out there was a third option: look for an alternative driver. I found a third-party application called VueScan that works with a range of scanners, including the S300M. It’s been working well for me; the only downside is that it’s a bit slower than Fujitsu’s driver. But given my use of the scanner, it’s not slow enough to merit buying a new device.

Thus far, Catalina has been great. I’m especially enjoying the new Sidecar feature, which allows me to use my iPad as a second screen when I’m on the go. So far, everything is working for me — including my old scanner. The lesson: if you’re contemplating upgrading to Catalina, but are holding back because of legacy software on your system, consider looking for alternatives.

On Google Reader

| Jorge Arango

Yesterday, I tweeted about missing Google Reader:

The tweet touched a nerve; lots of folks have chimed in, mostly agreeing with the sentiment or recommending substitutes.

To be clear, I still read RSS feeds every day. (I use Reeder on the Mac and iOS and synch my feeds using Feedly.) Although I’m open to exploring alternatives, I’m not unsatisfied with my current arrangement. (Ringing endorsement!) So I’m mostly not lamenting the loss of Google Reader’s functionality. Instead, I miss what Google Reader represented: a major technology company supporting a truly decentralized publishing platform.

Google’s brand imparted some degree of credibility to an emergent ecosystem. I suspect a nontrivial number of people must’ve tried RSS feeds because Google provided a tool to read them. It’s great that tools like Feedly, Reeder, Feedbin, NetNewsWire, etc. exist, but none of them have the broad appeal or brand power that Google does.

I said I’m “mostly” not lamenting the loss of Google Reader’s functionality. This is because while current RSS readers offer the basics, Reader was a natural, cohesive component of my personal information ecosystem. Unsurprisingly, it looked and felt like (and integrated with) other Google tools like Gmail and Google Calendar, which I was using extensively at the time. As befit a Google product, Reader also offered excellent search capabilities. None of the RSS readers I’ve tried since offer the same level of coherence and integration that I experienced with Google Reader.

I sense Google Reader was a casualty of Google’s primary business model: selling its users’ attention to the highest bidder. I doubt RSS provided the scale or control required to run a mass advertising business. IMO it’s no coincidence that Google pulled the plug on Reader at a time when centralized social networks (Facebook, Twitter) were gaining traction in the mainstream. (Google+, which the company had launched a couple of years earlier, failed to take off. I wonder if they saw Reader as competition for G+?)

Six years after Google Reader’s disappearance, we’re wiser to the limits of centralized control over news aggregation. Subjectively, I sense many people are rediscovering the joys of blogging. (And, like me, using the social networks mostly as a way to publicize our blog posts.) Podcasts — which are based on syndicated feeds — seem to be more popular every year. While I miss Google Reader, I believe decentralized syndication is an essential part of the web’s future — not just its past. Is the time right for Google (or any of the other major tech platform companies) to embrace the platform again?

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.