Posts From May 2012
I perform all my own stunts. Some people get sweaty palms when they look down from tall buildings, but for me it’s when it’s time to upgrade WordPress or migrate to a new server.
As nervous as I may get doing database- and server-related tasks, the things that I am comfortable doing — such as stylesheets and basic php functionality to make this site do spiffy things — are a lot of fun for me. I’m not a professional programmer, nor do I play one on the Internet, but I love taking time off from writing on occasion to tackle a web design project. It’s the sort of work I can do with the music turned up.1
I have never felt constrained by Coda. It is fast, reliable, fun to use, and the way it works with files makes a lot of sense to me.
As the saying goes, simplicity is the ultimate sophistication.
There is a challenge with apps like Coda that have much functionality. That challenge is to design the functionality in such a way that it is the user who discovers and then defines how simple or complex they want the application to be.
Coda 1 did this well, but Coda 2 does it better. There are so many options, features and functions within Coda that it seems there is nothing it cannot do. But even for the amateur programmers like myself, Coda never feels overwhelming or overbearing. It expands or contracts to the needs of its user.
Panic didn’t set out to make the best text editor, CSS editor, etc… They set out to make one single application that contains all you need to build a website. And Panic has done a great job at keeping each of Coda’s components concise, powerful and focused – giving you the features you need while not requiring you to learn 4 or 5 new applications simultaneously to be able to use Coda efficiently. Sometimes good development decisions are about what you don’t put in.
After its launch on a Monday morning in April of 2007, Cabel Sasser said: “This was by far the most complicated program we’ve ever built.”
Coda went on to win an Apple Design Award at WWDC in 2007 for Best Mac OS X Experience. And rightfully so — Coda was a groundbreaking application. Five years later comes Coda 2 — an application that is better than its predecessor in every way.
Coda 2 has kept all that was great about the original and improved all that was frustrating or confusing.
Using Coda 1 was like sleeping with a pea under the mattress. Or, as Joe Kissel said in his review, “like buying your dream car, only to find out that the seats are kind of uncomfortable and there’s no heater.”
The idea of a one-window web development tool that wasn’t built and priced by Adobe was a dream come true. Yet there was a slight frustration that accompanied the Coda workflow.
Web development usually consists of four (yea five) apps: (1) a text editor, (2) a web browser or three, (3) an FTP client, (4) reference material, and (5) perhaps the terminal.
Coda brought all of these apps together into one so that you wouldn’t need four or five different applications all open and running. It was good, but it was not great.
When I do coding for this site I use Coda as my text editor and FTP client, but that’s it. I still have a browser open in the background because switching between code view and preview always felt a bit clunky to me.
The appeal of Coda cannot be expressed solely by any comparison of features. The point is not what it does, but how it feels to use it. The essential aspects of Coda aren’t features in its components, but rather the connections between components.
The premier difference between Coda 1 and Coda 2 is its improvement between components. The workflow. Though each individual component (the text editor, the FTP client, etc.) has been improved upon, the most significant improvement to Coda is its central aim as a one-window web development tool.
Those who have been using Coda 1 as their primary web development app will love the update. Those who use other applications for their Web development may likely find Coda 2 to be a worthy companion.
It is the application I use and recommend for people looking to build websites. Now let’s take a look at some of the highlights in the new version.
The toolbar in Coda 2 is actually a document navigator. Like tabs in a web browser toolbar tabs are for different workspaces and documents. There are two tabs that are always there, always active, and those are the “Sites” tab and the “Files” tab.
The “Sites” tab is the standard start screen we know and love from Coda 1. It’s basically a favorites list containing the remote login information for any and all websites you hack on. Something new here is that sites can now be grouped together. Simply drag one site onto another as you would two apps from your iPhone’s Home screen.
The “Files” tab is basically Transmit integrated right into the app. This is a huge improvement to Coda’s previous FTP functionality. Coda has always used the same FTP turbo-engine from Transmit, but the visual file browser was not nearly as robust. If you’ve ever found yourself using Transmit and Coda at the same time, that habit may change with Coda 2.
After these two tabs, any additional open tabs are yours to set up as you need for your project. You can open multiple documents, a preview tab, a reference tab, and more. This is the meat of what Coda is all about and this is where things have improved the most.
The way Coda 1 handled workspaces and open files was awkward at best. And though I became familiar enough with it to feel comfortable, it was never quite natural — for example, a document tab could be both a file and a preview of that file.
In Coda 2, however, the new tabs and the way open files are managed is much more intuitive; this is the area that needed improvement and Panic has improved it greatly.
The tabs in Coda 2′s toolbar don’t just function different — they are completely redesigned. Visually, they have three optional states: Small Icon and Text; Large Icon and Text; or Text Only. You can select these from a contextual menu when Control-clicking on the toolbar, or you get them automatically if you resize the toolbar.
I prefer the Text Only tabs if only because I’m short on vertical screen space. However, the tabs with icons are tempting because they give you a live preview of that tab’s document.
For the Sites tab, Coda 2 will grab the Web Clip Icon in your root folder, assuming you’ve got one, and give you a high-resolution thumbnail image for the remote site you are currently working in. This beats the pants off a pixelated favicon.
To correspond with the fluidity of the toolbar and the different tab designs, even the traffic lights in Coda 2 have two different states. For the text only tabs you get the standard left-to-right layout. For the icon-based tabs, you get the top-to-bottom traffic lights akin to our old pal iTunes 10.0.
When you create a new document, it is saved to your local machine by default. If, however, you are in the middle of working on a live site and you want the file to be on your remote server, just grab the tab of your document and drag it into the sidebar file browser to upload it to the folder of your choice.
Alternatively, you can Control-click within the file browser and select the option for New File.
In Coda 1 a small blue circles showed up in the sidebar’s file viewer, just to the right of an unsaved document. Now unsaved documents you are working on sport that small blue circle within their tab as a way of letting you know the current working version of this file has not been saved to the server.
The iPad version of Coda (Diet Coda) uses these blue dots on the tabs in the file drawer as well.
If you’re going to have a one-window web development application, you need good in-app preview of the site you’re working on. This is something that never felt easy or natural to me in Coda 1, and so I still used Safari to view and check my changes.
But, thanks to the improved tabs, previewing your work in Coda 2 is much simpler.
You have four options for previewing:
A dedicated tab with web page loaded in it.
Split screen previewing that is side-by-side with the document you are coding.
Split screen previewing works quite well. You can code in the top window and preview your work in the bottom window. In fact, as you work, the bottom preview pane updates in real time as you code. Hit save and your changes are pushed to the server.
Previewing in another window. Ideal for multi-monitor setups. When your document is in Preview mode (the right-most breadcrumb) click the settings gear icon in the bottom-left corner of the window and choose Preview → New Window. A new Coda window will pop up with a browser preview of the file you’re working on. As you make changes to your document you see them live in the Preview window.
AirPreview: connecting your iPad as an external monitor like a boss.
Coda 2 will pair with Diet Coda on your iPad to turn your iPad into a dedicated window to preview the site you are editing in Coda.
You first pair your iPad with your Mac by pointing the camera at your Mac’s screen while a box flashes bright random colors. Then, anytime you have Diet Coda open on your iPad, you can turn the iPad’s screen into a secondary preview window.
Furthermore, the iPad preview auto-refreshes when you save your changes to the file you are editing in Coda 2. No more hitting save and then navigating to the browser and hitting refresh.
You don’t have to be working on the root file of your preview window either. You can be working on the CSS stylesheet, or a related php document, while viewing your rendered Index page. When you make changes to the file you are working on, then your previews are auto-updated and relevant changes are then shown. This makes many instances of Command-Tabbing and refreshing far less necessary, if not obsolete.
Pro-tip for the Sites tab: If you don’t want to use the auto-generated image for your site, you can Control+click on a site and choose to change the artwork.
Coda 2 cannot import the .seestyle settings for syntax highlighting from Coda 1.
The new way that auto-tag completion works is much more friendly. In Coda 1, when you typed an opening tag, such as
<div>then you would get the closing tag auto-inserted into your text immediately. If you were just starting out your opening tag then that’s all fine and dandy, but often times (at least the way I code) I would find myself placing opening tags in front of lines of code that I had already written. And then, Coda would auto-insert the closing tag right there at the front as well.
Well, Coda’s new format for auto-tag closing is much more clever. They wait until you begin to close the tag yourself by typing
</and then Coda plops in the rest for you.
Coda 2 does not support Lion’s auto-saving and versioning for local files.
If you buy the Mac App Store version, you get iCloud syncing of your sites. This, however, does not mean that your iPad version and Mac version stay in sync (yet). But if you have more than one Mac that is using Coda 2, then those sites will sync.
* * *
Coda 1 was ambitious. It takes a lot of guts (or, in some cases, naiveté) to build an all-in-one application for a task as extravagant as web development. It also takes self-control to keep that application from getting too big for its britches. Coda 2, while following in the ambitious footsteps of its predecessor, is also more useful and more elegant.
I have been using Coda for years, and all the updates in Coda 2 meet my needs almost exactly. But there was another need I had, and that was the ability to access and edit files on my websites using my iPad.2
And Panic has done it. They not only improved an already impressive one-window web development tool, they also built an equally-impressive one-app web development tool. It’s called Diet Coda for the iPad.
Diet Coda is an example of why the iPad is thriving as a personal computer.
Using FTP, Diet Coda is both a terminal and a text editor built for the purpose of making changes to files which are already on your remote server. Moreover, Diet Coda is the best name for an iOS app ever. If there were an ADA for app names, Diet Coda would win it.
Does the advent of Diet Coda mean professional web developers can now put away their iMacs and replace them with iPads? No. And that was never the intention.
Diet Coda isn’t meant to be a full-featured web-development tool for the iPad. Because, seriously, who is going to use an iPad for full-fledged website development? Virtually nobody.
But who wants to use an iPad to remote in to their server to update a file, copy a link, reboot something, or perform some other form of on-the-fly maintenance or editing? A lot of us.
My point isn’t that you can’t use the iPad for web development, but that most people won’t. And so why build an app to prove a point when you can instead build an app that meets genuine need just right? For this reason, Diet Coda is the best on-the-go web-development app you can buy. It’s not too much, it’s not too little; it’s just right and that’s the point.
What I like about Diet Coda is that it follows the same flow of working with files that Coda for Mac does. I have worked with a handful of other FTP / text-editing apps for the iPad and while they offer some features that Coda does not, they also make me shuffle my files around in a way that is not completely intuitive to me.
With Diet Coda I connect to my site, navigate to the file I want, edit that file, and then save my changes to the server. I don’t have to juggle both a remote and local version of the file — I just open it, edit it, and save it. This is how Coda 1 worked, it’s how Coda 2 works, and it’s how Diet Coda works. It makes working in Diet Coda feel comfortable and secure.
When creating an iOS version of a desktop app you can’t just drag and drop the code and click an “iPaditize” button. You have to balance the juxtaposition between the two platforms. Keeping the same core functionality of the Mac version, yet completely reimagined what the user experience and interface will be.
There are two dynamics to successfully building two versions of the same app, one for iOS and one for OS X:
Both apps need to feel native on their respective platform. The iOS version needs to feel like it belongs on the iPhone/iPad, and the desktop version needs to feel like it belongs there. This doesn’t just mean the buttons should be bigger to accommodate for fat fingers, it means the presentation of the core functionality, along with the flow of navigation and the user interaction within the application all have to pull together to form a well-developed iOS app that still has striking familiarity to its desktop counterpart.
Both apps need to feel like they are the same app. Meaning, Panic had to reconcile the two-fold need for Diet Coda to feel like a native iPad app while also feeling like the very same application they made for the desktop.
Because iOS and OS X exist side by side — two separate but similar platforms — we are seeing software innovation attain new heights as the two different platforms lean on and learn from one another. Put another way: iOS software is teaching us new things about Mac software and Mac software is teaching us new things about iOS software. The two are playing off one another.
The Omni Group is a prime example as ones who are helping lead the charge in this way. Their suite of iPad apps stand on the shoulders of their already award-winning desktop software, with OmniFocus being one of my favorite examples this. It started as a powerful and feature-rich Mac application and it was then perfectly ported to the iPad. In fact, I find the iPad version of OmniFocus to be superior to the Mac version in many ways, and I have no doubt that the next Mac version will be using many of the best components found in the iPad version.
We even see Apple doing this. With Lion and Mountain Lion they are taking much of the functionality and applications found in iOS and bringing it over to OS X for the sake of unification.
And, of course, Diet Coda is great example of Mac-app-gone-iOS. In addition to having the heart of its desktop sibling, Diet Coda is also filled with many iOS-esque details and innovations that delight.
There is the Super Loupe. The Super Loupe is the real steel deal. It is Panic’s take on the iOS magnification bubble for cursor placement, and it is clever, fun, and extremely useful.
If you have connected to a remote site and are in the file browser view, a tap on one of the four purple buttons in the Info Panel emits what I can only describe as a purple orb that radiates out from the button.
But the functionality of these buttons is also quite handy. You’re one tap away from copying a link, a URL, a file path, or the
imgtag with the source URL embedded (though it does not auto-detect the width and height when copying the image tag code).
Working with Files
Diet Coda makes it extremely easy to navigate around your remote server, working with live files, moving them, editing them, and previewing them. However, as I mentioned above, Diet Coda has no place for you to save files locally on your iPad. If you want to create a new file it must be saved to your remote server, and any work you do on server-side files is pushed back up to that live file when you tap save.
This is by design, and as such, it means there are some clever tricks for making sure you don’t lose your work when switching to another app for a moment, nor make an erroneous error to a live file.
If you have a document open in Diet Coda and then leave the app, the file is saved locally just as you left it, even if Diet Coda has to “force quit”.
In Diet Coda, though you are working with a file as it is on the server, you can preview your document before committing your changes. Diet Coda renders the web page as if the local version were the live version. This doesn’t work for dynamic files of course, only static ones.
Diet Coda is not perfect in every way, though. I do have a few requests:
I’d love to see support for Amazon S3, and more robust FTP capabilities such as being able to upload files that are on my iPad.
I wish I could duplicate a site’s details to more easily create additional sites that are subdomains that use the same connection credentials. (Or better: I wish Coda 2 and Diet Coda synced Sites.)
There is no master password for the app. Thus I either need to remember my FTP passwords and enter them every time I connect to a remote site, or else I allow Diet Coda to be freely accessible to anyone whom I let use my iPad.
(If you wish to have Diet Coda ask you for your FTP password every time you connect, simply leave the password field blank when entering the site info.)
Additionally I’ve found that Diet Coda can get memory constrained when working with large CSS files, or if too many documents are open in the Document Drawer. And though the app has crashed on me a few times, not once have I lost any work.
A Concluding Remark
To say I’m impressed and pleased with Coda 2 and Diet Coda would be an understatement.
My initial impression of Diet Coda is that it is the Tweetie 2 of iPad text-editing apps. As many people have proclaimed, Tweetie 2 was not just one of the best Twitter apps for iPhone, it was also one of the best apps for the iPhone, period. Although Diet Coda is still brand-new, it strikes me being a best-in-class code-editing app as well as a great iPad app, period.
- Writing, however, requires silence. ↵
- This isn’t so I can turn my iPad into my primary work machine, but rather it’s so I can leave my laptop at home more often without having to sacrifice anything. Though I prefer to work on my MacBook Air, I don’t want to be restrained if I’ve just got the iPad. Put another way: MacBook is now my “desktop” and my iPad is now my “laptop”. ↵
When it comes to pixels I can’t get enough. Ditto my need for a huge desk. I want a lot of pixels on my screen and I want a lot of space on my desk.
It’s not because I want to use these spaces to store application windows and external hard drives. Quite the opposite: I want to use this space for nothing. I work well when I’m sitting at a large and oversized desk that has little on it beyond a big glowing screen and a clicky keyboard. The same goes for my computer monitors. I like a lot of pixels available so that I can not use them.
Why this is, I’m not sure — it’s a part of my personality, but it’s also how I imagine my mind working. When the mind is clear like an open field on a blue-sky day it has absolute liberty to run and twirl and throw the frisbee as far as it can. There are no walls or hinderances or buildings that stand in the way of clear and imaginative thinking.
When I’m at my desk typing on my computer it means my mind is working. And the more open my physical and digital workspaces are then the more open my mental one can be.
In Praise of the 23-Inch Apple Cinema Display
My first Mac was a 12-inch PowerBook that sat on the wrong side of the excessive screen real-estate scale. It was the smallest and cutest computer Apple made at the time, and it had a screen resolution of 1024×768 pixels. I cut my teeth as a print designer on that tiny screen, learning the ropes of Photoshop and InDesign and giving myself a splitting headache. I constantly worked in a slouched over position, with my neck stretching forward to get my head closer to the screen.
After my first paid print job I used the funds to buy myself an external monitor: a 19-inch Somethingorother from the Tiger Direct catalog. A few years later I had saved enough for a Mac Pro and with it I bought a 23-inch Apple Cinema Display, a device that I consider to be one of Apple’s finest pieces of hardware ever.
I had spent many occasions in the Apple Retail store looking at the displays, and I read all of the famous Mac setups featured on Glenn Wolsey’s old blog. The 20-inch model was too small; the 30-inch was too big even though it entitled bragging rights; and so, by deduction, the 23-inch was just right. (I think Apple realized this as well and they cut the sizes of their Cinema Displays down to just the 27-inch monitor. This is a great size, it’s big enough to be big but not so much that you lose open applications.)
I have now been working on a 23-inch Apple Cinema Display for half a decade. I’m on my second one because my original was sold with the Mac Pro. You can’t find them as easily as you could even just a few years ago, especially if you want one in good condition.
What I like about the aluminum Apple Cinema Display is that it epitomizes what I consider to be the highest breed of products designed by Apple in California.
The front of the display is nothing more than a matte screen surrounded by an aluminum bezel. The bezel is not so fat as to distract for your attention. Nor is it too thin. Its proportions are sound.
At the bottom-center of the bezel is the Apple logo in shiny aluminum — subtle. The bezel wraps over the top and bottom of the display, and covers the whole back of the enclosure in a sheet of aluminum as well. The corners are rounded, the sides are white plastic, and the base is a hearty aluminum foot.
On the right edge are the only three buttons: one to power the display on and off, and two for adjusting the brightness of the backlights up or down. At the bottom right-hand corner of the front bezel is a small hole cut out with a white light that shines through. This light “breathes” as the old PowerBooks did when the computer is sleeping. When you turn the display on or off that small light gets bright all at once and then dims down to darkness again.
The greatest feature of all however, is what this display lacks: there is no glass panel glued to the front. The aluminum cinema display sports the great matte screens of yesteryear. And a CJ7 will always be cooler than a modern Wrangler.
What has kept me from upgrading to this next generation of displays found in today’s Apple stores has been that front glass panel. I have worked on these displays (and their iMac cousins), and I admit that they are nice and crisp and pleasing on the eyes. They pose well in pictures of our desks and they display colors and text vividly. They are also much easier to keep clean — the solid glass panel on the front makes it easy to wipe off any trace of dust and fingerprints without fear of damaging the pixels underneath.
In Praise of Retina Display Macs
My 12-inch PowerBook had a good long run. After it I bought a 15-inch MacBook Pro (the aluminum body kind that closely resembled the Power PC laptops that had come just before it). I bought the 15-inch MBP for a few reason: I wanted a laptop with more screen real-estate for the times I was working not at my desk, and Apple had discontinued the 12-inch lineup and replaced it with the 13-inch plastic MacBook which came in white or black. Those plastic laptops never appealed to me, which meant there was only one option: the 15-inch MacBook Pro.
Fast forward a few more years to the summer of 2011 where the laptop which superseded my MacBook Pro was a 13-inch MacBook Air.
Everything about the Air was appealing to me except for one thing: the screen. By the summer of 2011 I was no longer doing print design work and so I wasn’t in absolute need of the biggest screen I could carry in one arm. But my affection for a large screen remained. I was able to justify this conflict thanks to the fact that the 13-inch MacBook Air has the same number of pixels as my 15-inch MacBook Pro. Therefore it would provide me with all the same screen real-estate, just in a smaller and sharper image. I was okay with that; I have good eyes.
But there was a second drawback to the screen on the MacBook Air and that was the screen itself. Though it’s not adorned with a sheet of glass like you find on the modern MacBook Pros and iMacs, it does have a slight shine to it. It’s not matte, it’s glossy.
I thought long and hard about if I could handle working on a glossy screen. It seems like a trite detail, but if you’re a nerd then you understand. We all have our various trite details which can act as peas under our mattresses, and I feared that the MacBook Air’s glossy display would cause me to lose sleep at night.
In my mind’s eye I placed the glossy screen on one side of the scale and on the other I placed the all the rest of the hardware (the new i7 Core Duo processor, the Solid State Drive, the long-lasting battery, the Thunderbolt connection, the slim and light form factor). It was no contest and the scales tipped heavily in favor of the bells and whistles of the new MacBook Airs. I drove to the local Apple store and bought one.
And after all that the glossy screen has proven to be a non-issue for me. What a boring end to the story, right?
There is something that I left out, however. And it’s that all my time using my 15-inch MacBook Pro, I was wishing for a version of it that copied the Air’s form factor. A lightweight, teardrop-shaped laptop that was minus an optical drive and had a Solid State Drive and 15-inch screen. To me, at the time, that sounded like the ideal laptop.
You can do well to figure out future Apple rumors by simply betting on what seems obvious-but-is-not-yet. And a 15-inch MacBook Air strikes me as just such a device. It’s not “mind-blowing” because we can all imagine what it will look like. And it’s not “exciting” because we can all pretty much see it coming — surely it’s only a matter of time.
Earlier this week 9to5 Mac posted a rumor about the what an upcoming 15-inch MacBook Pro may look like. According to this rumor, however, the new MacBook Pro would look just like the current model but thinner, rather than sporting an Air-like teardrop shape.
The biggest talking point, however, isn’t about the size or shape of the laptop but rather the pixels on the screen. The next MacBook Pro is supposedly going to have a Retina display.
The iPhone 4 was too amazing to not push that display into bigger and bigger devices. Retina display Macs have been a long time coming. Last summer, with Lion, the phrase being whispered on the air was the Back to the Mac tagline which Apple themselves used when first demoing the new operating system. That tagline continues to stay relevant, because not only is the software of iOS continually influencing OS X, but we are seeing iOS hardware make its way “Back to the Mac” as well. The Magic Trackpad is a good example, “natural scrolling” is another, and next will be the Retina display.
The idea of a Retina display on a Macintosh sounds fantastic. The words I’m typing at this moment are onto my iPad with its high resolution screen, and the text looks stellar. Retina displays rock. Sure, there are downsides and ugly bits that a Retina display Mac would bring with it — such as non-retina applications and websites — and Marco Arment does a good job of articulating those.
I have the good fortune of using applications on my Mac that are developed by bleeding edge developers. In addition to the native OS X apps I use (Mail and Safari), the 3rd-party apps like OmniFocus, Yojimbo, Coda, Transmit, MarsEdit, Byword, iA Writer, and others which are all run by developers which I have no doubt will be quick to update their Mac applications to support Apple’s new high resolution displays.
While it’s true that non-Retina apps on a Retina screen are like sandpaper on the eyes, the tradeoff is worth it to me. I will suffer ugly graphics on the Web in exchange for print-like text, sharp high-resolution photos, and all the other elements of the operating system which will have Retina assets.
I heard someone mention that it’s not unlike iOS shipping without support for Flash. There was a short period of time when you didn’t get the “full web” when on your iPhone and iPad, but now, a few years later, I can’t remember the last time I visited a website and my iPad was sent back out to the cold thanks to its lack of Flash.
I began this article talking about how fond I am of big displays with lots of unused space. Contrasted against this truth is the fact that I also enjoy working from my iPad. My iPad is the smallest screen I work from.
Not including my iPhone (I don’t work on that device) I have three work screens. Listed in order of screen size, from smallest to largest, they are: iPad, MacBook Air, and Cinema Display. But listed in order of pixels, from least to greatest, they are: MacBook Air, Cinema Display, iPad.
The smallest working screen is also the one which sports the most pixels. Surely there is a connection here as to why I prefer to work from either my extra large Cinema Display or my extra dense iPad.
Retina displays are coming to the Macintosh — it’s only a matter of time — and the sooner the better.
Visual is a simple countdown timer for your iPhone. Instead of showing a stopwatch-like countdown, the app takes over your whole iPhone screen with a single color. It starts out green and slowly fades to yellow and then red as your time runs out. You can pick other color pallets if you like.
Last month I changed my email workflow to only allow myself 44 minutes per day for email checking — one 22-minute segment in the early afternoon and another 22-minute segment towards the end of my day. And I’ve been using Visual to budget that time. 1
There is no shortage of iPhone timer apps. iOS comes with a built-in timer, and if that’s not good enough for you, Due is a highly-recommended and splendid alternative. What I like about Visual is that the face of the iPhone doesn’t say exactly how much time I have (well, it does, in ultra-fine print at the bottom of the screen for those who just must know).
Instead visual conveys about how much time is left through the nature of the visual timer.
A countdown timer like this would never fly in a NASA control room, but for my office it works quite well.
My only two gripes with Visual are:
The icon. I’m not sure where it came from, but it sure doesn’t seem related to the rest of the app which is simple and well designed.
If you launch the app after the timer is done you are greeted with the “timer’s done” screen, rather than the launch screen for starting a new timer. Since you’re pretty much always are launching the app to start a new timer the app always requires an extra tap to get to the settings pane.
- My reasoning behind the 44-minutes of email routine could take up an article all its own. But, in short, my reasoning is that cleaning out my whole inbox every single day is an unrealistic goal. And so, instead of allowing the amount of email in my inbox to dictate how much time and attention I need to spend there, I’ve set my own time budget for how much I’m willing to give to my email inbox. And yes, I admit that I am in a unique and fortunate position that I don’t have to check my email as part of my job. It behooves me to check my email, but I have no boss or co-workers relying on me to read and reply to email. ↵