DEV Community: Kristian Lumme

App Design on macOS Big Sur

Kristian Lumme — Tue, 02 Mar 2021 17:49:44 +0000

In 2015, we covered the latest design changes in macOS on the Tower blog. At that point, OS X Yosemite had just been released, featuring a major overhaul of the user interface. Following in the footsteps of iOS, Yosemite moved away from a skeuomorphic interface towards a more flat, minimalistic design. At the same time, the Tower Git client was updated to adapt the new look and feel of OS X 10.10.

Well, the time is here again! macOS Big Sur has been released, and with it come comprehensive visual changes to the primary elements of the operating system, including windows, menus, icons and the dock. We’ve been hard at work making sure Tower feels right at home in this new environment. In this article, we’ll take a look at some of the design changes introduced in macOS Big Sur, and how we’ve applied these to Tower for Mac.

What motivates the changes to the user interface, and what is the long-term vision that drives and shapes these changes from version to version? Only Apple knows for sure. However, as spectators, we can certainly discern some overall trends. The Big Sur updates reflect some movements that have been going on for a long time.

Like OS X Yosemite, Big Sur seems to move in the direction of iOS visually. While it’s true that there’s more to macOS Big Sur than copying iOS, and while it may be more appropriate to say that the design of both iOS and macOS reflect the direction of the technology industry and of Apple as a whole, this statement does have a point. In an interview with MKBHD, Craig Federighi (Apple's senior vice president of Software Engineering) mentions the mental overhead required when constantly switching between the different interfaces of iOS and macOS. Making macOS feel more familiar for iOS-users reduces this overhead.

Apple has also been moving away from cluttered interfaces, towards sparseness and placing as much focus on content as possible. Whether you’re viewing photos, reading, or browsing your files, the content is featured prominently while available actions aren’t always immediately visible. With its increased spacing, reduced contrast and lighter icons, macOS Big Sur takes another step in this direction.

Changes in Big Sur

Having covered the general trends, let’s take a closer look at some of the visual updates in Big Sur! The look of windows is a good place to start. One of the essential elements of the user interface, windows receive some prominent changes:

Corners are more rounded than before.
Colors are lighter and contrast is decreased.
Increased spacing and more discreet icons contribute to the lightness of the interface.
Sidebars can now take up the whole height of the window.
The window title is integrated into the toolbar.

A Finder window in macOS Big Sur...

... and in Catalina.

An app can now specify an app-specific accent color, which is used for buttons, selections, and in sidebars. Selections have a new, rounded look, and many controls have been redesigned. Sheets have also been redesigned, now looking like modal popups, instead of folding down from the bottom edge of the toolbar.

Big Sur accent color, rounded selections...

... and a Big Sur sheet.

SF Symbols, a library of icons made by Apple previously available in iOS, is now included and used in macOS. These icons can be used in toolbars, sidebars and elsewhere.

App icons get a new style as well, with all icons now using a rounded rectangle shape. While the icons have been updated to correspond more closely to their iOS counterparts, they do retain some macOS touches. Traditionally, app icons in macOS have featured a more realistic style than in iOS, and many Big Sur icons sport quite a bit of detail.

Big Sur app icon design moving closer to iOS.

There are many more changes in macOS Big Sur than covered here. The dock is redesigned, as is the notification center, and there is a new control center (another change brought over from iOS). Menus look different, there are new system sounds, and more. In fact, along with the news of the switch to Apple Silicon — Apple-made processors — for Mac hardware, these changes were enough for Apple to decide to turn up the version number for macOS Big Sur to 11! Catalina, the previous version of macOS, has the version number 10.15, while macOS Big Sur is known as version 11.0.

Changes in Tower

If you ask us, part of what makes Tower great is the fact that it’s a native Mac app. Not only does this provide the best performance, but also the best integration with the operating system — the environment in which the app is used. As macOS users generally update quickly, it’s important that Tower adapts the design language of the latest macOS version. Of course, this can’t mean that Tower suddenly looks out-of-place on previous versions — while some changes can apply both to old and new macOS versions, some user interface changes should be restricted to users running the latest update. We’ve been hard at work updating Tower to take advantage of what macOS has to offer, and we think the result is a Git client that looks and feels better than ever!

At first glance, you’ll notice that Tower adapts the full-height sidebar look of macOS Big Sur. This change doesn’t only affect the sidebar: it has consequences for the toolbar, the window title and the navigation bar. The buttons in the toolbar, pushed to the right, now share space with the window title and with elements from the navigation bar, like the clone button. The navigation bar itself has been removed, for a cleaner look. The services and bookmarks icons, previously in the navigation bar, now show up in the main toolbar, at the top of the new full-height sidebar.

Tower 6 running on Big Sur...

... and on Catalina.

Big Sur comes with a new look for selections, with rounded corners and different spacing. Naturally, Tower adopts these, except for in some places where rounded selections wouldn't make visual sense.

Icons have been updated: we now use SF symbols along with some custom ones in the sidebar, the toolbar and in the quick actions popup. These icons have a lighter look than the ones previously used. In addition, the sidebar icons and selections now use the system accent color, so if you go into your macOS preferences and change the accent color, you’ll see your choice reflected in Tower’s sidebar.

A change which shows up on older macOS versions as well concerns the remote activity area. This area, showing ongoing pushes and fetches, for example, used to be visible all the time. Now, it only shows up when there are actual remote activities going on, otherwise, it stays out of the way.

Finally, our app icon now adapts the rounded-rectangle shape of other Big Sur apps.

Of course, this is just an overview. There are a lot of changes beyond the main ones described here. Positioning and spacing has been adjusted throughout the app, as have the colors of graph lines, badges and file statuses. The preferences window has been rewritten in order to facilitate easier updates and changes in the future. Tower has been recompiled and optimized for running on Apple Silicon. All in all, we are very happy with how Tower Big Sur turned out — we think this is the best-looking, most usable version of Tower yet!

How We Work on the Tower Git Client

Kristian Lumme — Tue, 02 Feb 2021 09:44:58 +0000

The team behind the Tower Git client has been fully remote since 2015. During this time, we've faced the challenges of getting things done without sharing an office, but we've also seen the benefits. Working on Tower and associated tasks like support, marketing and websites in a completely distributed team has given us ample opportunity to develop our culture, and we've come to a few insights about how to work effectively remotely. We've had a post on how we work in the pipeline for some time and, as current world circumstances are bringing discussion on remote work to the forefront, we figured this would be a good time to share some thoughts and tips.

Culture and Values

"The best way to find out if you can trust somebody is to trust them."
— Ernest Hemingway

Any discussion of our culture has to start with trust. Trusting the people on the team is the foundation of our other habits, from asynchronous communication to self-direction. Some managers freak out if they don’t micromanage people — they feel they're not in control. We don't want to work in an environment where people only do things because they fear the consequences if they don’t. Finding people that care about what they are doing and who take pride in the accomplishments of the team is of paramount importance.

The rest follows quite naturally from the foundation of trust. We’re a small company and everyone is welcome to contribute their ideas and comments when it comes to what to work on. Given agreement on the most important tasks to focus on at the moment, people are expected to manage their own time, attention and priorities.

As mentioned, we eschew the “always available” culture and do asynchronous communication for the most part — we want most time to be available for getting things done, not taken up by responding to communication or sitting in meetings. If there is a truly urgent problem that needs immediate attention — like the website being down — we switch channels, to phone for example. In a similar vein, we are “offline by default”. This doesn't mean that none of us are connected to the internet (though some ISPs would argue differently); rather, it means that our default mode is to be working away without the distraction of having to respond to everything that comes up, or having to appear to be “online”.

Finally, we stick to a forty-hour work week, expecting people to put in their focused time and then leave work behind for the day.

Setting Expectations

When it comes to culture, we find that setting expectations is important! We document our expectations and choose tools that reinforce them. Knowing, for example, that urgent problems will be communicated through an appropriate medium helps to encourage the default mode of asynchronous communication in day-to-day work. Most importantly, we try to live by our word. If everyone around you responds to all communication in three seconds flat, that's the culture, not whatever the document says. Finding that others embrace these principles makes you comfortable doing so as well.

Needless to say, we didn’t have everything figured out regarding distributed culture coming out of the gate. On the contrary, like probably every other company making the switch from co-located to remote work, we were stuck in our old ways to begin with. This included undocumented workflows, many all-hands meetings but no recurring formats, synchronous communication, and a lack of tools. The processes outlined here are something that we’ve developed through the years, and that we expect to continue developing in the future.

Tools and Software

“To the man who only has a hammer, everything he encounters begins to look like a nail.”
— Abraham Maslow

Technology is what allows us to implement remote work in the first place. Naturally, we use a large number of different services and applications, including but far from limited to Twist, email, GitHub, Asana, Zoom, Confluence, Calendly, and Google G Suite to get our work done.

What tools you use is not the most important thing, but you can choose tools that align with and reinforce your culture — or clash with it! As an example, though we’ve used Slack in the past, we now use Twist as a team chat tool. Twist does not show online/offline indicators or who has read a particular message. It does allow for organisation of topics and gives you control over who gets notified for a particular message. This alleviates the feeling that you need to respond right away and helps you find the important points in a discussion even at a later date.

Challenges

“With freedom comes responsibility.”
— Eleanor Roosevelt

When it comes to working together, not seeing each other in person can create friction in a variety of ways. Sharing and understanding current status, progress and any blockers takes deliberate communication. Through text communication or even video chats, communicating and reading emotional state can be hard. A comment that comes off as friendly or joking in person might come across as blunt in an email, and it’s hard to gauge if a person needs some support with what they’re doing or if they’re happily working away and best left alone for the moment. Learning to communicate effectively through text is a requirement — this may present a challenge, but may also cultivate clearer and more thoughtful communication.

Connecting People

In addition to the professional aspect, only meeting your colleagues through text communication, with the occasional video chat, can feel challenging on a personal level. In short, remote work can feel lonely! You may not be quite up-to-date on what’s happening in the life of the people you work with. We do a few things to alleviate this, including peer 1-on-1s and weekly check-ins... but the truth is that in a distributed team, you have to be deliberate about nourishing your personal connections outside work, as you’re not going to get quite the same personal contact on a daily basis that you would get in a co-located team.

Nevertheless, we do try to combat these issues by meeting in person three times per year (in non-COVID times, that is)! The get-togethers are great opportunities to get to know each other a little better, and we find that the better you know the people you work with, the easier communication becomes. When it comes to day-to-day communication, we also find that too much is better than too little. We try to be open about what’s going on in our lives and our work, including the challenges — not only does sharing these things with your peers feel good, but it also helps them understand where your mind is at.

Discipline

People have joined the team with varying amounts of remote-work experience. Regardless of at what point in your life you start working remotely, there is a learning phase. When working at a dedicated office, the start and end of your workday are naturally delineated and the environment provides some discipline by itself. When working from home, you quickly find that you need to learn that discipline, and that if you don’t set routines for yourself, there will be none. The routines help establish boundaries between work and life outside of it. As you’re largely your own manager, organizing your own time and tasks is a must.

If you have kids or other family members around, it may be difficult for them to understand that you are present but not available for interaction. Personal relationships may require more effort, as staying inside becomes easier. The same goes for physical movement — it’s easy to underestimate how much commuting to an office makes you move around but if you spend all day, every day on your couch, you’ll notice the difference!

Benefits

“You mind putting on some pants? I find it a little weird I have to ask twice.”
— Phil, The Hangover

The freedom of being able to choose where and when you work is a benefit to a degree which really can’t be overstated. Some people are more productive in the mornings, others in the evenings, and as our many team members with kids can attest to, being able to structure your day to give you lots of quality time with your family members is priceless! Having complete control over your working environment (well, apart from aforementioned kids…) is also very helpful. There’s also the benefit of not having a commute, which can save you a lot of time per day.

As previously mentioned, in our distributed team, you take on a lot of the responsibility for managing yourself and taking ownership of your projects. The responsibility can be challenging, but also communicates trust and inspires you to bring your best. Owning a project makes it more meaningful to you than if you were just handed task after task from someone else, without much say about which problems to solve and how to solve them.

People and Processes

With a co-located team, a company is limited to finding employees among those living in or willing to relocate to a specific area. Remote work greatly increases the available talent pool, as you’re basically looking for people from the whole world. In practice, time zones are a consideration, as it’s helpful to have a bit of everyone's workday overlap, but with some flexibility you still have a lot of places to choose from!

Working remotely also helps you document processes and decisions — simply because you have no other choice! This can bring clarity and thoughtfulness to processes. The fact that everything needs to be written down may feel like extra work initially, but very quickly, you find that it saves a great deal of effort. In addition, the documentation is immensely useful when onboarding new members of the team.

How about cost? Not necessarily, though this is a common perception; while not having an office is a cost saving in itself, the costs for travel and get-togethers along with some extra tooling for remote work add up so that reduced costs are not necessarily a benefit of being fully remote.

Final Words

A common theme among the challenges and benefits mentioned above is that remote work forces you to be deliberate about many things that happen by themselves in a co-located workspace. Routines and work/life boundaries must be constructed with intent. Communication, whether about work or something personal, takes effort and care. The same goes for personal connections, status updates and even exercise. However, having to think about these things explicitly sooner rather than later may also be very useful! Being intentional up-front instead of having processes and decisions “just happen” helps with clarity and with creating good habits, and may also make any problems apparent sooner. This way, many obstacles can be turned into assets.

That’s about it for this look at the way we work on Tower. Remote work certainly brings its challenges, but for us, this is still an amazing way to work. A culture based on trust reduces overhead and inspires everyone to take responsibility for moving things forward. Self-direction and self-motivation are a must, as are building routines, nourishing your personal connections outside work and taking care of your health.

If there’s some aspect of our work culture you’re interested in hearing more about, feel free to reach out — maybe there is material for another post looking at some topic in more detail.

Until next time, hope you are all staying safe and looking out for each other!

How We Built Undo for Git

Kristian Lumme — Tue, 24 Nov 2020 06:54:50 +0000

Tower 4.0 on the Mac introduced a special feature: undo is now available in our Git client! Seeing as we're far from the first application implementing undo, you may ask yourself what's so special about being able to hit CMD+Z in Tower? Given that actions in Tower can perform quite complicated Git operations under the hood, there's more to the feature than meets the eye. A lot of work went into making undo feel intuitive while keeping the user's work and data safe. In this article, we'll give you a look behind the curtains of Tower development, describing how the undo feature was conceived and implemented.

The Idea

As mentioned, the idea of an undo feature is not novel, and the idea did lay on our roadmap for quite some time. Before moving to a subscription-based model, we tried to align big features with major releases, and undo was originally considered for Tower 3, but did not make it in. Nowadays, bigger features don't depend on major releases, but the undo feature was still a bit unusual for us in terms of scope and the time it took to implement. We generally try to add things in shorter sprints but development of the undo feature was spread over a long period of time. We also wanted to deliver a complete, polished feature, not release it piece-by-piece.

For some actions in Git, the expected outcome after undoing is obvious, and reversing the action is easy. For others, the outcome is less clear and implementation is complicated. From the very beginning, work on this feature consisted of implementing the obvious cases, trying them out in real-world scenarios and seeing if they felt and worked as expected, while iterating on the more complicated cases to make sure they were robust and felt as natural and intuitive as the simple ones.

Starting Work on Undo

Work on the undo feature proceeded intermittently — while the first commits for the feature happened back in March 2017, the bulk of the development came later, while other work took priority in the meantime. Alex, our CTO, and Heiko, our Mac developer, began with a proof-of-concept, implementing undo for some actions where the desired state after undoing is clear and simple — undoing a "delete branch" action, for example. The implementation of Git operations as discrete actions in Tower allowed us to work on undo one case at a time, implementing and tweaking it for one action without affecting another. The feature was actually shipped with Tower, but disabled for end-users through a developer flag. This allowed us to use and test the feature internally in our own daily work for a long time.

Being able to test the feature in our daily work was useful for a couple of reasons. For one, we wanted to find out whether the feature really was useful — would we actually use it? Also, we had to find the sweet spot for each action: what felt right, what felt wrong, and was there anything we expected to be able to undo, but weren't? As mentioned, in some cases deciding on the correct outcome and implementing undo was relatively simple, in others, decidedly less so.

As work proceeded on other aspects of Tower, undo was taking shape as well. It generally seems to be the case that one underestimates the complexity of upcoming work, and so it was in this case: while we knew the feature would come with its challenges, perhaps we didn't realize exactly how challenging it would be. In the words of Hofstadter's Law, "It always takes longer than you expect, even when you take into account Hofstadter's Law".

Challenges

There's a wide gap between implementing a feature as a gimmick and actually making it feel natural, intuitive and solid. In Tower, actions happen asynchronously relative to the UI, so right away, we had the challenge of making sure the undo feature could handle this — for example, repeatedly undoing and redoing some action could not result in something breaking or data being lost.

In order to undo some more complicated actions, we had to save additional data for each step undertaken by the user, so that we would have all the information necessary to get back to the previous state in case the user decided to undo. An example of this occurs with some operations involving the working tree. The working tree is complicated, with many different potential states for files: files can be modified, staged, they can have merge conflicts and so on.

Rebases and Merge Conflicts

As a concrete example, let's say you're rebasing a branch on another branch. As your commits are being replayed on the target branch, during one of them, you get merge conflicts in multiple files. At this point, Git (and Tower) will stop to let you resolve the merge conflicts. Here, there are several interesting use cases for undo. A user might resolve several of the files with merge conflicts, only to find that one of the files was not resolved in the correct way, and then decide to undo to get back to resolving that file. In addition, the user might resolve the merge conflicts for that commit and either abort or continue the rebase, only to want to undo and go back to the previous rebase step.

The solution for both of these scenarios involved implementing snapshots for the working tree. As the user acts on the repository, these snapshots capture the state of the working tree along each step and allow Tower to back up when undoing. In the case of undoing a resolved merge conflict for a single file, undoing essentially just means going back to a previous snapshot. When continuing or aborting the rebase and then undoing, there's not really a way in Git to get back to the previous state, Here, Tower has a mechanism for replaying the steps previously taken while rebasing (using the snapshots), to get back to the state before undoing. There were a few options for how this could have been implemented — we could have re-used the commits created as the user performed the rebase sequence, and restored the state down to the actual commit hashes after undo, but that would have meant tracking the state of the rebase kept by Git in internal files. This is something we avoid, as this is an implementation detail and can change — Tower only uses the same Git commands that are available to end-users. The solution used, with snapshots and replaying of these, doesn't result in the same commit hashes, but the content of those commits is the same.

There's another scenario to keep in mind when restoring some previous state: it's possible for a user to do an action in Tower, then work with the repository on the command line, then go back to Tower and try to undo the last action done here. This may be a somewhat unlikely scenario, but still may not result in breakage or data being lost. In the kind of workflow described above, this is handled by the fact that the snapshots are implemented using patches — if there are conflicting changes, the patches simply won't apply.

Bringing the Feature into the Real World

As mentioned, during work on this and other features, Alex and Heiko were able to test and develop the undo feature, making sure it performed as expected. Undo is (hopefully) not a feature you use every ten minutes in Tower, but when you do reach for it, it is highly important that it feels natural and robust. For this purpose, real-world testing and iteration was key — the critical parts of the feature are unit-tested, but it's hard to write tests for how intuitive a feature feels to use.

What we found was that the feature did come in handy — Alex recalls a lightbulb moment of mistagging a commit and realizing that, instead of going to find the tag, deleting it, and creating a new one, he could just hit CMD+Z. As the snapshots for the working tree were implemented and used in the more complex flows, these, too, fell into place.

Beta And Release

In December 2019, the feature hit real-world testers in the Tower beta version. This went fairly undramatically — some bugs were found that actually turned out to originate in other parts of the code, but were exposed by undo. In the beginning of February 2020, the feature was released in Tower 4.0 — to the delight of many users, judging by the feedback. Seeing as undo is such a simple operation from the user's point of view, but can have such wide-varying effects on the underlying Git repository, the way it all comes together makes it quite satisfying to use.

We've found it to be useful in our day-to-day work to be able to quickly go back from merging the wrong branch, making an erroneous commit or deleting the wrong file, for example. Of course, we use Tower internally, and developing Tower involves a great deal of messing around with Git repositories to test it out — in these scenarios, the feature is very handy indeed! All in all, we are very happy with the feature and glad that our users seem to enjoy it too!

camsoft2000

@camsoft2000

@gittower While I’m pretty competent with git cli I do use tower for comitting and merging etc. Used the undo feature today to roll back a local comit and it worked seamlessly. Super impressive. Beats messing around with reflog.

16:42 PM - 27 Feb 2020

0 1

Steve U

@uffel

Just undid a code merge with cmd-Z. @gittower you’re the best.

19:37 PM - 11 Feb 2020

3 7

Jami Gibbs ✌️

@jamigibbs

What an awesome feature just added to Tower! You can now CMD-Z some pretty complex git workflows.🤯 I know a lot of folks swear by open source or editor based git clients (ie. free) but Tower has been worth every last penny for me. git-tower.com/blog/tower-mac…

15:02 PM - 10 Feb 2020

0 1

The Bigger Picture

In our work on Tower, we constantly strive to make our users more productive, providing access to the powerful features of Git in the easiest, most intuitive way possible. In addition, one of the benefits of a graphical user interface like Tower's is discoverability — you may come across a feature that you didn't know existed. The command-line is very powerful and has its benefits, but discoverability is not necessarily one of them.

The undo feature provides a perfect example of how this vision is implemented. Depending on the context, the simple act of undoing can result in a wide variety of operations on the underlying Git repository. The feature is useful for beginners as well as for Git veterans, and it's as discoverable as can be. You can use it without stopping to consider what goes on behind the scenes, and hopefully you will nevertheless find that it does what you expect, every time!

Epilogue

There is a nice coda to the story of undo. When Alex and Heiko started looking at enabling partial stashing in Tower, they figured it should be easy, as Git supports partial stashing since 2.13.2. However, it turned out that the behavior of Git in this case was not quite what we expected and hoped for. Nevertheless, the work on snapshots for the undo feature allowed us to work around this issue, implementing a feature which might not have happened if it wasn't for the earlier work on undo! Partial stashing was released in Tower 4.3.