tonio loewald's thoughts on usability, programming, games, and other stuff
Roku 3 vs. AppleTV
Leave a reply
Roku 3 (image provided by Roku)
I just got spammed by Roku (we owned a second-generation — I think — Roku, which we hardly used and eventually gave away, so I guess they have my email address). I’m not really in the market for a Roku since it doesn’t let me watch iTunes content (in which we have a significant investment) and AppleTV lets me watch pretty much everything I’d watch on a Roku, but it is interesting to see Roku out in front of AppleTV in significant ways.
Remote control has a headphone jack. This is a huge missed opportunity for Apple, especially since many Apple “remotes” (i.e. iPhones, iPod Touches, and iPads) already have wireless connections and headphone jacks. (Incidentally, some kind of fine-tuning of lipsync would probably be a good idea.) If you go back to my broken hub post, this kind of falls under the question why A can’t stream audio/video to or remotely control B for any A and B where-ever it would make sense in the Apple universe? It didn’t occur to me that AppleTV’s should be able to stream audio to other devices, but they should.
Search is federated. The company that built fast, federated search into its operating system still won’t let you search for a movie across content silos — I need to search for Phineas & Ferb in iTunes, Hulu, and Netflix separately. Again, it’s worse than that because Apple doesn’t build enough of the AppleTV software into its remote — I should be able to do content searches on my iPad and then simply tell my AppleTV to jump straight to a result rather than use my iPad to painfully generate a query on my AppleTV.
It also looks like Roku’s remote control apps are smarter — i.e. more smarts in the app rather than simply emulating a crappy remote control.
Roku also seems to be stressing how fast the new device performs. (Given Tivo’s ever-more-torpid UI and AppleTV’s overally network-dependent performance, this is no minor thing.)
If I were to provide a wish list for AppleTV, a lot of the items have already been addressed by the new Roku. (I assume that, given HBOGO now streams to AppleTV that an app for AppleTV is in the works.) Here’s hoping that AppleTV is about to get some serious love.
Fun with the Nikon V1
Leave a reply
100% crop of adolescent cheetah (National Zoo, Washington DC). The camera nailed focus, and the image is decently sharp, although clearly the lens is not matching the sensor’s resolution.
Just before Christmas I got a pretty good deal on the Nikon V1 (I paid more than I need have since the price dropped even further after I got mine). I ended up picking up the V1 with the 10-30mm kit lens (which is a pretty decent macro lens in case you’re wondering) and the FT-1 adapter, allowing me to use my F-mount lenses — notably my 70-300mm VR — with the V1.
Adolescent cheetah — straight out of camera (converted from RAW)
My previous blog post shows three photographs I took with the V1/70-300 combination at the zoo, but this was all hand-held and pretty terrible. I’m actually surprised any of the pictures were usable at all (a few of the red panda pics were lovely). On my second excursion I brought my new monopod (a Christmas present). Definitely better but (a) I need more practice with a monopod and (b) an 810mm (effective) lens probably needs a tripod.
Adolescent Cheetah — minor fixes in iPhoto. Click for full-size image.
When I pixel-peeped at the unretouched image I noticed some chromatic aberration. Loading the image in iPhoto fixed it automagically. So I added a tiny bit of saturation, retouched two tiny blemishes (not the camera’s fault — the cheetah had some gunk stuck in its fur), and performed a single unsharp mask.
To my eye it’s sharp — not quite tack sharp, I think the pixel density of the V1 sensor is beyond the lens’s resolving power (but it looks like the 70-300VR should do just fine on a 24MP FX sensor) — and the background looks fine. Not bad.
RAW Deals
Leave a reply
I’m pretty paranoid about my RAW photos. I keep them (and a lot of other stuff) backed up locally (albeit in desultory fashion) and in the cloud via Crashplan. My initial backup took nearly three months, but once I got over that hump it’s pretty much seamless and my computers are usually only an hour or two ahead of backups (unless I leave them in sleep mode for days, which I do — but it’s not like data are being created while they’re asleep).
My own history of failure
Three years ago I worked with some former colleagues and friends on a startup called Photozen and later PurePhoto. The domain still exists, but it’s become a online photo art dealership (I was also involved in that pivot — I implemented the initial data migration by building a hack tool for consuming PurePhoto’s data from specific photographers’ accounts and pushing it to Shopify.)
But, at the time, we avoided dealing with RAWs despite the fact that, in my opinion, that’s where the real opportunity lies. There’s a lot of mythology surrounding RAW files — I’ve just had an email exchange with the redoubtable Thom Hogan (a very smart guy who, after an illustrious career in hi-tech, is making a good living as a pro photographer, which is no mean feat) over the importance of knowing how to set white balance on your high-end digital camera.
Acorn’s UI wrapped around Apple’s RAW converter — see that temperature slider?
In my opinion as a RAW shooter there is almost no importance in memorizing this operation — I can second-guess the Auto-WB setting later. On the rare occasion when I need to shoot JPEG (e.g. to optimize my use of the continuous shooting buffer) I can figure it out, but it’s not that common. Thom is under the impression that white balance drives the exposure meter which determines the quality of RAW capture. I can’t verify this experimentally (my experiments indicate otherwise) and it doesn’t make sense to me (as I understand it, Nikon polls an RGB sensor array and then fuzzy-matches the result to an image database to calculate exposure meters — why you’d want to put a white balance calculation in the middle of that escapes me).
Of course Nikon doesn’t help us by using a proprietary and encrypted RAW file format (the actual image data is accessible, but the metadata — which bears directly on a discussion like this — is encrypted). In any event, there’s this mystical attachment to the original RAW file, as though it contains secret sauce, when in fact it’s just a bunch of floating point values that can be “losslessly” converted into some other format (e.g. DNG) or quasi-losslessly converted into — say — lower resolution pixel-binned images (suppose you want to keep dynamic range, but don’t need resolution). As far as I can tell, demand for tools that deal with RAW files intelligently is so low that such tools do not exist, but they’re perfectly doable.
Everpix
So along comes a really neat looking startup called Everpix which promises to solve every photographer’s most annoying workflow problem — unifying all those different silos of photos under one management umbrella. Upload a photo to your iPad, snap a photo on your iPhone, dock your camera to your Mac Pro, every device you own can access every photo.
And they even promise to do things like figure out which shots are in near-identical sequences and automagically pick the best one, and automatically detect incorrect exposures and blurry shots so you don’t need to sort them out.
Of couse it only does this with JPEGs. Grrrr.
Aside: after writing this post, I discovered that — apparently — Everpix can’t upload from my main Aperture library. I also did some Googling to see if anyone else has figured this out — Adobe Revel makes no mention of RAW files even in its FAQ (seriously, no-one wonders about RAW backup to the cloud?) and SugarSync (which looks very similar to Everpix) also makes no mention of RAW support anywhere. My guess, if you’re studiously not mentioning it anywhere on your website, you aren’t dealing with it.
Look guys. You’ve gotten me to install your software on every machine I own. You can see the darn files. How about (a) figuring out which images are blurred or underexposed before you upload them, or (b) using the metadata I’ve provided (e.g. which photos I’ve given star ratings or bothered to fine-tune). This will help filter signal from noise and with the insane amounts of bandwidth you save you can upload the damn RAW files.
Note that I proposed this exact idea to my colleagues working on PurePhoto and it was set aside for after release. (Release never really happened.) Here’s the thing — I don’t need a better image editor. I don’t need a tool for sorting my pictures into folders. I really don’t care about JPEGs because those are “prints”. I can replace them. I need to deal with baggigabytes of photos, 90% of them crap, and I need it to be seamless and handle RAW.
A typical RAW file is three times larger than the corresponding “fine” JPEG. So, support RAW files and figure out a way to avoid uploading 70% of the images and you’re ahead. You’re way ahead because now you’re doing something useful.
Here’s another way of looking at it: if you save 100% of my JPEGs you’ve done nothing useful. If you save 90% of the RAW files I care about (missing 10% because your filter algorithm is imperfect) you’ve done me a huge, huge service, and I can become smarter about finessing your algorithm and you can improve your algorithm over time.
Go forth and implement something useful.
The Browser as Word-Processor
Leave a reply
Like, I think, most web developers, I assumed that making a decent WYSIWYG editor that works inside a browser is difficult and tedious, and assumed the best solution was to use something off-the-shelf — especially since there are what look like pretty good free options such as TinyMCE and CKEditor.
Upon close — or even superficial — examination, these editors (and there are a lot of them) seem to pretty much suck. As a simple pons asinorum try the following test (incidentally, the editor in the latest version of WordPress scores quite well here):
Create a simple document with a heading and a couple of paragraphs of text.
Bold a couple of words in one of the paragraph (not two consecutive words).
Now, while observing the editor’s toolbar, try a series of selections:
Select a bold word
Select a plaintext word
Select from a bold word to some plaintext
Select within the different paragraphs and headings
Select across two paragraphs with different styles
If you didn’t encounter several WTF moments then either the state of off-the-shelf JavaScript text editors has improved markedly since I wrote this or you’re not paying close attention.
Google Documents — errr Google Drive — handles all this with aplomb, which is to say it behaves exactly like Microsoft Word (which is kind of dumb, but at least (a) what users probably expect, and (b) reasonably consistent). E.g. if you select a mixture of bold and non-bold text the bold toolbar icon will be “unlit” indicating (my colleague and I assume) that when you press it the selection will turn bold. In most of these editors either the bold button exhibits random behavior or goes bold if the selection starts in bolded text. (The latter at least accurately foreshadows the behavior of the bold button: more on that later.)
Assumed Hard, Left Untried
My experience as a JavaScript coder has been that there are only really two levels of difficulty for doing stuff in JavaScript — not that hard and practically impossible (and every so often someone will surprise me by doing something I assumed was practically impossible).
I knew that there’s a trick for editing any web page, e.g. the following scriptlet will allow you to edit any web page (with spellchecking for bonus points):
So, I knew that something like this was easy. What I didn’t realize was that at some point in the browser wars Microsoft implemented pretty much all of Microsoft Word (modulo some UI glitches) into Internet Explorer, and then everyone else simply implemented most of their API.
So, for example, the following scriptlet used in conjunction with the preceding one allows you to bold the current selection in any web page:
javascript: document.execCommand(“bold”);
If nothing else, you can have a lot of fun defacing web pages and taking screenshots:
While I knew about the contentEditable “trick”, I didn’t put all this together until — frustrated by the huge and unwieldy codebase of CKEditor (which, at bottom, is really just a custom UI library that calls execCommand) and unimpressed by alternatives (aside from Redactor.js, which looks pretty good but is not free or open source) I found this thread on Stackoverflow.
I cleaned up the example and had a working text editor in a few dozen lines of code. (I’d post them but they’re written for a client. I believe the whole project will eventually be open-sourced, but right now it hasn’t been. If and when it ever gets open-sourced, I’ll link the code. Failing that I may write my own simpler version for personal use (and integration with Foldermark).
document.execCommand implements most of the functionality you need to write a perfectly good word-processor from scratch in a browser. In fact, if you’re willing to put up with some UI quirks, pretty much all you need to do is implement some trivial UI components. Almost all the implementations out there create a complete blank document inside an br by default, but it’s perfectly viable to edit inline in a div, especially if you’re planning to use the ambient styles anyway.
The beauty of writing your own word processor using execCommand is that the browser gives you fine-grained access to all events, allowing you to arbitrarily fine-tune the low-level behavior of your word-processor. Microsoft Word, for example, has always had unfathomable UI quirks.
What don’t you get?
First, you do get pretty solid table support.
You don’t get fine control over styling, although there’s nothing to stop you from implementing a CSS editor of some kind (disguised or not). From my point of view, the default behavior of the browser word-processor is to be very styles-driven, and that’s a good thing. It’s not so easy out-of-the-box to, for example, set a specific point size for text.
Some execCommand commands don’t work very well. E.g. you can implement a “hiliter” using execCommand(“backColor”…) but there’s no way to toggle it off (unlike bold) so to properly implement it you need to directly mess with the DOM, which — given the way selections are represented, can be a tad ugly.
There’s stuff that is simply difficult because you’re in a browser. E.g. without implementing some kind of service platform (or perhaps leveraging an existing one) you’re not going to be able to drag-and-drop a picture from your desktop into a document. It would be fairly straightforward, I suspect, to integrate DropBox with a word-processor to allow drag-and-drop images and attachments — anything that can be represented by a url is, of course, golden.
Most of the missing features from the free word-processor in your browser are what you’d expect. E.g. anything to do with overall document structure: automatic index and table of contents generation, footnotes, endnotes, headers, footers, and so forth. None of this stuff is hard to do in a browser. The real problem is support for printing — browsers generally suck at targeting printers — so you’re not going to replace Quark or InDesign — but if you’re targeting ePub rather than paper, I don’t see why you’d want to use anything else.
Final Thoughts
The advantages of “owning” your word processor’s codebase are enormous, especially if you’re trying to integrate it into a complex workflow. You can fine-tune exactly what happens when a user hits delete (e.g. we need to track dependencies — was this paragraph based on that paragraph template or not?), and what is editable or not. You can do validation inside input fields while allowing other text to be edited free-form. It’s pretty wonderful. One day, perhaps, there will be free off-the-shelf editor that solves key UI and workflow integration issues, but we’re a ways from there.
Creating UI Atlases in Photoshop Automagically
3 Replies
A little over a year ago I was working on a game engine for a successful toy company. The project never ended up being finished (long, nasty story which I’ll happily tell over beers), but one of the interesting things I did for this project was build a Photoshop-to-Unity automatic UI workflow. The basic idea was:
Create UI layout in Photoshop, with one “root level” layer or layer group corresponding to a control.
Name the groups according to a fairly complicated naming convention (which encapsulated both behavior and functionality, e.g. how a button might change its appearance when hovered or clicked and what clicking it would do).
Press a button.
Select a target folder (which could be inside a Unity project’s “Resources” folder, of course).
And point a script at the folder.
This worked amazingly well and allowed me to adjust to changing client requirements (e.g. random UI redesigns) very rapidly. But along the way I decided there were significant design issues with the concept, one of them being that the images needed to be texture-atlases (b) for performance reasons, but more importantly (a) because you needed to adjust import settings for each image (you can’t even select multiple images and change their import settings all at once — maybe this is fixed in Unity 4).
Another obvious problem was the embedding of behavior in names — it was convenient if you got it right the first time, but a serious pain in the ass for iterative development (either change the name in Photoshop and re-export everything or change the name in Photoshop and then edit the metadata file, and… yuck).
Anyway, I’ve had the “perfect” successor bouncing around in my head for a while and then the other day it struck me that someone probably has written a Photoshop image atlas tool already, and I might be able to rip that off and integrate it with my script.
Turns out that (a) someone has written an image atlas tool for Photoshop and (b) that the key component of that tool was a rectangle packer someone else (sadly the link is defunct) had written, implementing an algorithm documented here.
So that’s what I spent New Year’s Eve doing, and the result — Layer Group Atlas — is now availble on github.
For the more visually-minded, you start with a UI design in Photoshop. (Stuff can overlap, you can have multiple states set up for controls, etc.) The key thing is each “root level” group/layer corresponds to an image in the final atlas (and yes, transparency/alpha will be supported, if a group/layer’s name starts with a period then it is ignored (as per UNIX “invisible files”) while a group/layer with an underscore will only have its metadata exported.
For every layer (other than those which were ignored) metadata about the layer is stored in a JSON file. (One of the reasons I didn’t take this approach with my original tool was the lack of solid JSON support in Unity. I — cough — addressed that with another little project over the holiday break.) The JSON data is intended to be sufficient to rebuild the original Photoshop layout from the atlas, so it includes both the information as to where each element is in the atlas, but where it was in the original layout.
Finally, the script creates and saves the atlas itself (as a PNG file, of course).
Aside from the CSS sprite support I mention in the comments in a TODO — an obvious thing for this tool to be able to do would be to export a bunch of CSS styles allowing the images in the atlas to be used as CSS sprites — there’s one more missing thing: a Unity UI library that consumes the JSON/atlas combination and produces a UI.
