Saturday, August 30, 2014
Ten years ago, Bee Docs Timeline was born out of the idea that a member of a legal team could record events as a witness was describing them and then show the resulting timeline chart to the witness for confirmation. Two main parts of this challenge appealed to me as a product designer. First, quick real-time entry of the data. Second, a clear and professional presentation of the data that did not require lots of tweaking.
Both of these activities remain central to the design of Timeline 3D. The upcoming release will have a new interface design that further clarifies and reinforces these features. In order to understand the coming changes, I first want to review the design of the software as it exists today.
Here is an image of the current version of Timeline 3D for OS X (v3.9):
The main layout of interface has stayed basically the same for the past ten years. A layout of your timeline fills most of the window. This graphical presentation dynamically adapts to the contents of your document as well as the size of the window.
Double-clicking an event reveals an edit form that allows you to add or edit information like the event title, date, and media. You are responsible for that information as well as the date formats, colors, font size, and image sizes. The software is responsible for finding the best way to position everything in the timeline based on the these settings.
This structure had many advantages over timeline product that came before it. Notably, it removed the time consuming task of arranging event positions and tick marks. It also looks nice and works great for timelines where most of the events fit on a single screen. In the beginning, before event notes and media were an option, most of the timelines that customers created did fit on a single screen.
However, there are some down sides to this arrangement. It muddies the division of responsibility between the software and the user. When you want the timeline layout to fit more compactly, it involves changes to the timeline elements so that the software can change the timeline layout. This is confusing to many people at first.
The whole structure of editing your data within a dynamically changing timeline chart also does not scale very well. If you have one hundred events, for example, changing the date of an event may cause it to move completely off screen as the layout adapts. Then you need to go scrolling to find it.
Furthermore, the layout logic is complex behind the scenes and may take a few seconds to computer for a large timeline. The software can feel sluggish when it is constantly calculating the layout as you edit your content.
Finally, screen sizes on Apple products were fairly predictable when I introduced Timeline 3D. Now, the screens you work with every day can cover a huge range. Everything from a 3.5” iPhone to an 11” MacBook Air to a Mac Pro with multiple 4K displays.
The existing layout works well for very large displays, but it involve lots of side scrolling on the smaller displays which represent Apple’s most popular devices.
In the next Development Log, I will introduce a new design paradigm that addresses these issues in the upcoming version of Timeline 3D for OS X Yosemite.
Wednesday, August 20, 2014
I am planning to use this blog to share some of the technical details that I am working through for the upcoming version of Timeline 3D for OS X Yosemite and Timeline 3D for iOS 8.
After the conceptual design of a major new release, usually the first code that I develop is centered around the document format. I need a document format that can meet the goals of the release and that can also have a migration path from the previous formats the software has used.
New platforms and features have new requirements. After all, Timeline 3D was originally designed before the iPhone, iPad, and iCloud, not to mention the changes in the Mac platform during that time. Timeline 3D also did not originally support embedded images, movies, and audio.
Timeline 3D is almost ten years old and has supported six different file formats in that time. These formats include a custom binary format, SQLite Core Data store, XML Core Data store, as well as the ability to import and export tab-delimited text.
The file extensions have been txt, bdt, bdt2, bdt3, and bdt4 (short for Bee Docs’ Timeline). The new format will have a file extension "TL3D".
For the new version of Timeline 3D, my main goals have been cross-platform compatibility and support for syncing data. To this end, I designed a file format that is a folder structure of text (JSON format) files and media files in their native format (JPG, PNG, PDF, MP4...). Each event in the timeline has it's own folder with a data file and media files.
The new format is inherently cross-platform because it is just text and media files. There is nothing OS X specific, iOS specific, or even Apple specific about the format. If I wanted to build Timeline 3D for another platform or have a web server generate Timeline 3D files, the file format would still work.
The new format is also atomic. Change the tags in an event and only one little text file needs to be saved and synced. Change the image in an event and only two image files need to get synced (the media you added and a jpg thumbnail).
Since QuickLook and Spotlight were introduced, I have stored the thumbnail, preview, and search data within the file format. If I did this in a synced app, you could potentially be syncing large multimedia data every time there is a minor change to an event title or date. So, the new format uses an external QuickLook and Spotlight generator embedded in the Timeline 3D app. That information is now generated by your Mac as needed and not synced with the file format.
While the file format is not an aspect of software that customers think about often, the file format is the foundation of the features and performance that are critical to the app. The new format should be a great foundation for Timeline 3D for the next decade.