Archive for April 3, 2015

Friday, April 3, 2015 [Tweets] [Favorites]

XCTest: Areas for Improvement

Brian Gesiak (via Ole Begemann):

There are a lot of things that XCTest does really well. Below are some suggestions for what it could do even better, in my order of my personal preference.

My number one would be a way to automatically show the full log entry for each failing test. Right now, even with a behavior set up to show the report navigator and navigate to the current log, I still have to click at the top to show Logs instead of Tests, then click the expansion triangle to see the full log entry for the first test. And neither of these operations has a keyboard shortcut.

Must Fix for Next Release

Craig Hockenberry:

This fix was submitted two weeks ago on February 2nd. A week later it went into review and was quickly rejected. The problem was that a buy button was accessible from our Help window.

[…]

My issue is the way that we must fix these problems. In this particular case, the issue was resolved by editing some HTML on our server, not by changing anything in the app itself. But we still must submit a “new” binary and go through the lengthy review process again. This is a huge waste of time for both developers and app reviewers (who are clearly lagging behind these days.)

I think there’s an easy way to fix these minor transgressions that would benefit both parties: add a new kind of approval with strings attached. A “Must Fix for Next Release” state where the app can go into “Ready for Sale” but the issue remains in the Resolution Center.

Truncated Text in Mobile UIs

Ole Begemann:

As an app developer or designer, you should treat most cases where you conveniently resort to truncating text as a failure in your design. There are certainly exceptions to this, and especially if you deal with user-generated content you have to set a limit—nobody wants item titles spanning a dozen lines or more. For “normal” content, however, the default should be to display the full text. If that means an item title requires four lines, then give me four lines.

[…]

If you really think you need truncated text, you should at least provide the user with a way to see the whole thing without having to leave the current screen. Apple used to do this in the Music app. A long tap on a truncated song title would display a popover with the full title. This feature is gone in iOS 8, however. Another option might be to let users expand text by tapping on the ellipsis, but I still think these workarounds are worse than just showing the full text from the start.

I feel like I spend my day clicking to tell Xcode to show the rest of truncated error messages and unit test failures.

Aperture, Capture One, and Lightroom Walk Into a Bar

Jochen H. Schmidt:

As a registered developer I’ve installed Photos for OS X and have started to build an opinion on it. I actually like it — it is incredibly fast and some of its tools (like the retouch brush) are the best working implementations I have seen so far. But it is also very clear that this cannot replace Aperture today. Regardless of that, the infrastructure around Photos is how photos will be managed on Apple devices from now on. So it is likely that it’ll be a part of our future workflow even if another program replaces Aperture. Unfortunately it is not yet known which third-party vendors will offer some kind of integration with this new system or what that will look like.

[…]

I will edit a photo in Aperture, Lightroom and Capture One. The example is chosen to teach an important lesson; it is often wrong to quickly assume that something is impossible within an application. The paths are different — and sometimes more tedious — but in almost all cases you can get very comparable results from any of those programs. If not, try harder! To get to this point, you need to learn a programs strengths and quirks. Don’t write-off something to early!

Jochen H. Schmidt:

The result is looking much better than the one in Aperture. This example clearly shows why so many users trying Lightroom are shocked about the results they can get.

[…]

With both Lightroom and Capture One I easily can get better results than I got using similar techniques in Aperture. But is this really the whole story? Actually no; this kind of pushing deep shadows out of a photo with high dynamic range doesn’t really work with Aperture’s shadow slider. The solution is to drop the black point to zero and use the levels or curves tool to raise the shadows.

[…]

One fact is undenyable though: It is much easier in Capture One or Lightroom. The reason for that is very simple; the tools in those programs are written with such situations in mind. These are not just simple linear shadow level adjustments; there is a set of non-linear curves behind them which are carefully crafted to give natural results, even in the extremes. This is not a limit of the engine; it is a feature of the user interface which hides such complexity behind a simple linear looking slider.

[…]

When comparing Lightroom to Aperture I mostly miss the ease of use. While Lightroom’s tools work exceptionally well, the user interface and the catalog organization is something you may really have force yourself to like.

[…]

Capture One doesn’t only look similar to Aperture, it has a lot in common. The UI is more like Aperture and more configurable than Lightroom. The quality of its output it often said to be better than Lightroom.

Bob Rockefeller:

This is similar to my experience. Both Lightroom and Capture One have somewhat better develop tools. Aperture is far and away better at photo management.

Optionaldelusion:

I use Lightroom at work, but it never felt as comfortable as Aperture, even 5 years later. I have been experimenting with Capture One and like it as the best Aperture replacement so far. The most annoying missing features for me are global before and after (WTF? This is such a basic feature. You can do before/after only on each adjustment brick).

The current situation is a mess. Aperture is in maintenance mode, and its photo development tools lag behind the competition. None of the alternatives seem to be able to easily migrate files out of Aperture while preserving the organization (projects, albums, stacks, keywords). Only Photos.app can preserve Aperture’s non-destructive edits and use Photo Stream, and it’s the most limited in terms of managing photos, the area where Aperture still has a big lead. Right now, the least bad option seems to be to keep using Aperture. There are still professionals using it who at some point will need better migration tools, aren’t there?

Update (2015-04-08): Jeff Carlson:

Unfortunately, there’s no way to assign geo information to photos that don’t already have it. For example, if I shoot several photos of a location with my iPhone, I can’t copy that data to photos shot at the same place with my DSLR.

[…]

If you’re a longtime Aperture user, Photos is definitely a step back. Or rather, it’s the clear signal that says it’s time to look for other professional photo pastures. I can’t recommend Photos as a full-time replacement, although I can envision situations where it would work alongside Aperture, such as creating small libraries for sharing with clients who don’t own Aperture (both iPhoto and Aperture can open a library after it’s been converted, but edits don’t sync).

Serenity Caldwell:

No, it’s not Aperture. It’s got a long way to go before it’s ever going to be Aperture — and honestly, Apple may be ready to cede the true pro-editing market to Adobe and the like. But for the vast majority of users — beginner to prosumer alike — Photos for OS X is more than enough for your photo management needs.

[…]

There aren’t any brushes, to my great disappointment. The loupe is gone, replaced with Multitouch pinch-to-zooms, as are some of the more advanced management features. And you can’t edit your images in an external editor, or properly work with a reference library unless you disable iCloud Photo Library.

Writing a Great App Store Description

Stuart Hall:

Sure this is a chicken and egg problem, but if you have any stats to brag about don’t hold back!

[…]

Selling a story of the person your potential customers want to be is what you are trying to achieve.

Preprocessor Abuse and Optional Parentheses

Mike Ash:

While coming up with macros that would justify this [UNPAREN()] construct, I built a nice dispatch_once macro for making lazily-initialized constants. Here it is:

#define ONCE(type, name, ...) \
    UNPAREN(type) name() { \
        static UNPAREN(type) static_ ## name; \
        static dispatch_once_t predicate; \
        dispatch_once(&predicate, ^{ \
            static_ ## name = ({ __VA_ARGS__; }); \
        }); \
        return static_ ## name; \
    }

Here’s an example use:

ONCE(NSSet *, AllowedFileTypes, [NSSet setWithArray: @[ @"mp3", @"m4a", @"aiff" ]])

Then you can call AllowedFileTypes() to obtain the set, and it's efficiently created on demand. In the unlikely event that the type contains a comma, you can add parentheses and it will still work.

Model Widget Controller (MWC) a.k.a.: Apple “MVC” Is Not MVC

Marcel Weiher (tweet, comments):

As far as I can tell, this architectural style comes from having self-contained widgets that encapsulate very small pieces of information such as simple strings, booleans or numbers. The MVC architecture was not intended for these kinds of small widgets […]

With a widget, there is no complex model, not filtering being done by the view. The widget contains its own data, for example a string or a number. An advantage of widgets is that you can meaningfully assemble them in a tool like Interface Builder, with a more MVC-like large view, all you have in IB is a large blank space labeled ‘Custom View’. On the other hand, I’ve had very good experiences with “real” (large view) MVC in creating high performance, highly responsive user interfaces.

Update (2015-04-06): Martin Fowler (via Hacker News):

Probably the widest quoted pattern in UI development is Model View Controller (MVC) - it’s also the most misquoted. I’ve lost count of the times I’ve seen something described as MVC which turned out to be nothing like it. Frankly a lot of the reason for this is that parts of classic MVC don’t really make sense for rich clients these days.