Unredacted

Achievement Unlocked: January 2017

hello@redalemeden.com (Reda Lemeden) — Thu, 02 Feb 2017 09:52:55 +0100

Amidst all the depressing stuff going on, it is sometimes healthy to celebrate the little victories of everyday life. Here is a round-up to follow up on the one I wrote a little over a year ago.

2016 Restrospective

Between a new job, a house move, and a flurry of depressing news, my productivity took a hit in 2016. I was nevertheless able to do some fun things on the side:

Built and launched Speedster, a native bandwidth speed testing app for macOS. The feedback was very positive, but I struggled with the business model. As of now, the app is no longer available on the App Store, and version 3.0 is in the works (more on that later).
Launched then open-sourced Markoff, a lightweight Markdown previewer app for macOS.
Published three more articles in the Designing for iOS series that I started back in 2015.
Customized an arcade stick 🕹 and had a ton of fun doing it.
Designed a macOS replacement icon for Undertale.
Released ImageScout 1.0, a Swift implementation of fastimage.
Made a visualization on Swift 3.0 Access control.
Gave a talk about Swift API guidelines at Cocoaheads Stockholm.

January 2017

Code

Even though I’ve been writing less code outside of my full-time job, I managed to do a complete rewrite of Speedster 3.0 since last September. The app is now written in Swift 3.0 and no longer relies on the SpeedOfMe API for the tests (good riddance). A good chunk of my time off last month went into revisiting the UI and hunting down a couple of timeout issues that I’d like to fix before pushing the first beta.

On the open-source front, I managed to release Gifu 2.0 after 3 months of testing. The new version is written in Swift 3.0 and introduces a new protocol-based API that makes the library a lot more versatile.

Last but not least I managed to remove all anayltics from my websites. Yay privacy!

Design

I took a little break from code and spent some time refreshing the Speedster icon. I swapped the color palette and added some extra details to the needle as you can see on the Dribbble shot.

Podcasting

We resumed recording Tentative and the 1st episode of the season is already out! We discussed our new year’s resolutions in a quite spontaneous and laid back episode.

Writing

A little over ten years ago, I started a manga (Japanese comic) side project. I have been sporadically revisiting it since, adding tiny bits to the story and characters.
As time went by however, I started losing the spark that initially got me going.

Last month, I discarded all but the name of the main protagonist the overall tone of the story. A new direction that will hopefully get the creative juices flowing and help me keep the momentum.

Creative writing aside, I’d like to push these updates more frequently to stay motivated and keep everyone interested in my side projects in the loop.

Speedster: A Retrospective

hello@redalemeden.com (Reda Lemeden) — Tue, 17 May 2016 01:50:22 +0200

Last year, I had the ~~not so~~ brilliant idea to build a connection speed testing app for OS X. Between a full-time job and summer vacations, it took me about 6 months to wrap up a 1.0 using the SpeedOfMe free-while-in-beta API. Speedster was born.

Speed tests are a tricky business. I wasn’t convinced that the app would work for everyone, so I made it free. I also capped the number of daily tests per user to not get my API key revoked, and added an IAP to remove that limitation for good measure.

Shortly after submitting 1.0 for review, the app was rejected for violating section 2.9 of the review guidelines:

2.9 Apps that are “demo”, “trial”, or “test” versions will be rejected. Beta Apps may only be submitted through TestFlight and must follow the TestFlight guidelines

It seems like I wasn’t the only one sailing uncharted waters here. After a couple of back and forths, the app went live on February 1st. Here are some relevant numbers from the first month:

Downloads: 14k.
IAP: 212 units.
Revenue: $620.
API usage: 20k requests.
Conversion: 1.5%.

Most of the revenue was generated during the first 2 weeks as the weekly average dropped from $285 to $23 by the end of the month.

On February 20th, I woke up to an email from SpeedOfMe announcing their pricing plans and prompting me to update my billing information.

SpeedOfMe API plans.

Uh-oh.

Going with the Pro plan as the only reasonable option, I projected cumulative revenue and costs for the next 12 months, as they taught me in business school:

Projected cumulative revenue/costs (purple/orange).

This did not bode well. Even an optimistic revenue projection wasn’t enough to offset the costs for more than 3 months. Without recurring revenue, Speedster would not be sustainable on the long run.

After 24 hours of hesitation, I pulled the trigger on the Speedster Hero IAP and replaced it with consumable tests packs in 1.1. Here’s how things went since:

Daily revenue between March 1st and May 12th. Total: $148.

Oops. Consumables aren’t popular outside of games for a reason. The app made a measly $148 since March 1st and the pricing tweaks I did in the course of the last two months did not move the needle.

Remember that projection graph from earlier? Now it looks like this:

Readjusted cumulative revenue and costs projection (purple and orange respectively).

Did these changes make things worse? Absoluely. Do I have a clue why? Maybe. Let’s look at some ★☆☆☆☆ reviews:

I would stay away from this. Says free but its more like test three times and you must buy it. — Jatilq

no ping and 3x per day? — Ojaste

Why pay for a speed test when there are dozens of websites that provide this for free? limit the free version to 3 daily tests? $4 for unlimited? I will use speedtest.net for free — Legatony

The list goes on, but I will stop here. The gist of it is that the vast majority of users do not see enough value to justify paying for a consumable IAP.

With downloads hovering around a weekly average of 600, the prospects of a surge in revenue are bleak. Something’s gotta give.

Weekly downloads. Total as of May 12th: 21442.

In my last attempt to make this work, I am introducing some breaking changes in 2.0. Here’s an outline:

The app will no longer be free.
Users will be prompted to use their own SpeedOfMe API keys.
Existing Hero customers will be grand-fathered until further notice.
Test packs will remain as a secondary option for those who don’t want to manage their own API keys.

Will these changes net me a few more ★☆☆☆☆ reviews? I betcha. But at this point that is the least of my concerns.

To be continued.

Announcing Nope for Safari

hello@redalemeden.com (Reda Lemeden) — Mon, 28 Dec 2015 22:30:00 +0100

Two months ago I started working on Nope, a content blocking extension for Safari 9. Today I am happy to launch a stable version and get more people to try it.

Another Content Blocker?

There is no shortage of feature-packed ad blocking extensions such as AdBlock, Ghostery, and Disconnect. But as effective as these can be, they rely on JavaScript to identify and block resources, which has a non-trivial performance cost as Benjamin Poulain outlines on the WebKit blog:

The reason we are unhappy about the JavaScript-based content blocking extensions is they have significant performance drawbacks. The current model uses a lot of energy, reducing battery life, and increases page load time by adding latency for each resource. Certain kinds of extensions also reduce the runtime performance of webpages. Sometimes, they can allocate tremendous amounts of memory, which goes against our efforts to reduce WebKit’s memory footprint.

The new content blocking extension APIs in WebKit were designed to solve this very problem by compiling the rules into an efficient bytecode format that executes for each request, eliminating the need to run custom scripts code to determine what should be blocked and what should not.

After trying out the new batch of content blocking extensions in the hope of finding a replacement for AdBlock, I decided to take matters into my own hands and start from scratch with an increased focus on performance and privacy.

How it Works

Once Nope is enabled, every website you visit will fall into one of these three categories:

Yep: Nothing is blocked.
Nope: Third party resources belonging to any of the enabled categories (ads, tracking, social) are blocked. This is the default behavior.
Mega Nope: All third party resources are blocked, regardless of whether they are on the rules list or not.

You can view a list of all the (sub)domains that you’ve already categorized in the settings accessible from Safari > Preferences > Extensions > Nope. It’s also possible to manually edit the comma-separated list to add new (sub)domains or remove existing ones.

You can set the behavior for a specific domain or subdomain using the toolbar button.

API Limitations

Currently the content blocking APIs don’t expose the blocked resources to the extension. This means that there is no way of displaying what has been blocked outside of the Console logs in the developer console—not a great user experience for the average user.

Those who are happy to make this—hopefully temporary—tradeoff will see improved Safari performance, especially on sites that load dozens of third party scripts.

Logging blocked resources in the Safari Developer Console.

Roadmap

One of the goals that motivated me to work on Nope is to make an open-source blocking database that anyone can contribute to. Since the initial database I scrapped together ended up breaking a large number of popular sites, I opted for the open-source Disconnect database to get things off the ground more quickly. Going forward, I would like to drop this dependency and move the rules to a separate repository for more flexibility and transparency.

So, how about you give Nope a try and let me know what you think by opening issues or pull-requests on the repository?

Achievement Unlocked: 2015 Edition

hello@redalemeden.com (Reda Lemeden) — Sun, 27 Dec 2015 12:02:37 +0100

It’s that time of the year where we mull over what we accomplished in the past twelve months. Here is my list.

Stopped using Google products for personal use. Migrating my half dozen Gmail accounts was the hardest part. That and finding a viable replacement for YouTube. Spoiler: It does not exist.
Deleted unused online accounts. This includes Linkedin, Hulu, and other online retailers. Needless to say, I had some unpleasant experiences during this process.
Uninstalled Flash and Java on OS X. Surprised I didn’t get to this sooner.
Enabled two-factor authentication when available. Authy and 1Password for the win.
Launched a Mac app on the App Store. A utility that brings native IP geocoding to OS X.
Designed a mobile game. An unforgiving space survival with a whiff of nostalgia.
Co-hosted a podcast. Props to Kyle Fiedler for putting up with my never-ending rants.
Co-organized a Swift workshop. It was a lot of fun, especially the part where I had to sit back and listen to Jack Nutting explain optionals.
Released a Safari extension. It serves to scratch my own RSS discovery itch.
Got interviewed. It’s on Workspiration.
Visited San Francisco during WWDC week. It was totally worth it, even without a ticket.
Avoided buying an Apple Watch. Believe me, this one was particularly challenging.
Earned a Platinum trophy on PSN. Better yet, it’s from Bloodborne.

tvOS HIG: Too Long; Didn't Read

hello@redalemeden.com (Reda Lemeden) — Mon, 05 Oct 2015 00:39:09 +0200

I often joke about the HIG being an acronym for Highly Ignored Guidelines.
This is an effort to change that, at least for tvOS.

The user interface of Apple TV.

Glossary

Click. One-finger quick press on the center of the touch surface. The primary way of triggering actions.
Click-and-hold. One-finger long press on the center of the touch surface. Used to trigger context-specific actions, like entering edit mode.
Focus. The state of the currently selected interface element.
Parallax. An effect applied to focused app icons and content elements using multiple layered images.
Siri Remote. The Siri-enabled remote used as the primary input method for Apple TV. It comes with 6 buttons, a touch surface, an accelerometer, and a gyroscope.
Swipe. One-finger press followed by a quick movement in any direction on the touch surface. Used to move focus vertically or horizontally.
Tap. One-finger quick press on one of the four directions (top, right, bottom, left) of the touch surface. Used for single-item directional navigation.
Top Shelf. The area above the first row of apps where featured content of the focused app appears.

Update: My colleague Jack Nutting pointed out that clicks require you to press the touch surface until it clicks, whereas taps don’t.

General

Design with multiple simultaneous users in mind.
Prefer showing old data to no data at all.
Avoid excessive animation.
Avoid using alerts unless it’s for a critical user decision. When you do, provide no more than two choices.
Don’t display your logo throughout the app UI.
Use the system video player to get advantage of all its interactive features.

Focus

Make focus obvious using labels, transforms, and other effects.
Use parallax on focused elements to make the UI more responsive to user interaction.
Prefer light backgrounds so that focus shadows remain visible.

Controls

Keep the difference between click and tap in mind. See the glossary.
Avoid using taps for triggering actions other than navigation.
Avoid using standard gestures to perform non-standard actions.
Avoid defining new gestures to perform standard actions.
Make sure your controller-compatible game works with the remote as well.
Always enable the Play/Pause button on the Siri Remote. If you are running out of ideas, make it at least perform a click.
Use gestures to move focus, not content. For instance, a left swipe would move focus to the left, making the content move to the right.
Use gestures to move content when displayed full-screen. For instance. a left swipe on a full-screen image would move the image to the left.

Use the tab bar for the main navigation of your app.
Allow your users to navigate back to the previous screen or out of your app/game using the Menu button.
Don’t display a back button.
Keep your content structure simple for easier navigation.
Prefer text, more specifically nouns and verbs for your tab titles.

Visual Design

Design your interface for a 1920 x 1080 pixels (16:9) screen in mind.
Use @1x resolution for all image assets.
Use an opaque background layer when making your layered images.
Provide at least one static Top Shelf image (1920px by 720px) if you don’t have any dynamic content to showcase.
Use the sRGB color space.
Favor muted color for better results on highly saturated TVs.
Prefer top-to-bottom, light-to-dark gradients.
Prefer horizontal layouts.
Leave 60 pixels on the top and bottom, and 90 pixels on the right and left as padding around the edges of the screen.

Text

Use San Francisco Text for text 39 points or smaller, and San Francisco Display for text that’s 40 points or larger.
Put text in the top-most layer of your layered images.
Use the built-in text styles to take advantage of features like Dynamic Type.
Use title-case in your text buttons.
Avoid combining both icons and text in buttons.
Try to limit text-input in your app since typing on the Apple TV can be tedious.

App Icon

Use a layered image (2-5 layers) for your app icon (1280px by 768px for large version and 400px by 240px for the small one).
Leave a padding around the content of your foreground layers.
Don’t include screenshots in your app icon.
Avoid text in your app icon, unless it’s part of the brand.

React Native: Initial Thoughts

hello@redalemeden.com (Reda Lemeden) — Sun, 29 Mar 2015 16:00:00 +0200

I spent a couple of days toying with React Native since it was open-sourced by Facebook last week. Here are my initial thoughts as someone who works with both iOS and Web development:

The Good

Immutable user interface. You no longer have to track state in both the model and the view; the latter is a function of the former. As soon as the model changes, React Native re-renders a virtual tree of the view hierarchy, then applies the delta to the native views. This approach feels superior to bindings or FRP, and is certainly light-years ahead of the official APIs.
Instant feedback loop. Once you build your app in Xcode, you can instantly refresh it from within the simulator using Command + R. You can even enable auto-refresh and forget about it. Going forward, I will dearly miss this feature in every non-React project.
Perceived¹ performance. I haven’t experienced any hiccups while working on a simple navigation-based app. The interface is 100% native and performs like one.

The Bad

Javascript.
No Swift support. Native modules should be written in Objective-C.
Additional abstraction layer. If you already do iOS development, you will be relearning a lot. For instance, ListView is the new TableView.
SDK limitations. Unless you want to subclass an unhealthy amount of UIKit using Objective-C (hint: I don’t), you will be rather restrained in what you can do out-of-the-box. I have yet to figure out how to change the barTintColor of a NavigatorIOS, the UINavigationBar equivalent.
No Interface Builder support. I typically use storyboards as a visual representation of user flow. Perhaps more importantly, I enjoy having the freedom of using the right tool for the job.
Component-based file structure. Handling styles, view hierarchy, and business logic all in one file is a step backwards. Poor style reusability is one direct consequence of this approach.
StyleSheet is not CSS. You will be quickly disappointed if you adventure outside the few CSS-inspired properties that React Native ships with.
Styling nested view controllers is a pain. You are taken back to the root view controller after each refresh.

The Meh

Flexbox. The authors missed the opportunity of offering a saner API and favored sticking to the official spec instead.
Chrome Dev Tools. Browsers are doing too much already.

Even though a good number of these issues is very likely to be addressed as the framework matures, I find the abstraction overhead off-putting considering the current limitations. On the bright side, React Native introduces concepts that could potentially change the way we build native applications, and I am looking forward to seeing how that will unfold.

Purely based on perception with with no benchmarks to back it up. ↩

IPinator

hello@redalemeden.com (Reda Lemeden) — Sat, 07 Mar 2015 12:24:52 +0100

I am happy to announce that IPinator is finally live on the App Store. It’s a utility app and Notification Center widget that geocodes your external IP address and displays it alongside your local one for easy copy-pasting during local development, VPN setup, etc.

Application window and Notification Center extension.

IPinator is written in Swift and uses Argo for JSON parsing and Llamakit for Result. The code-base is straightforward, save for one limitation related to the inability to display an MKMapView in a Today extension. The solution I came up with involved generating a map screenshot and passing it to the extension as an NSImage.

If you’d like to write about IPinator, feel free to drop a line for a promo code.

Back to Writing

hello@redalemeden.com (Reda Lemeden) — Sun, 01 Mar 2015 01:16:33 +0100

It feels like forever since the last time I wrote something. And it kind of is, given that I haven’t updated my personal blog ever since I joined thoughtbot in 2012. That was due to a combination of lacking the time to do proper research outside work hours and finding better venues for technical writing.

In a way, I was trying to spend my time fixing the things that irk me rather than writing about them. Actions speak louder than words has become my motto. But as time went on, I started to realize that writing about something as way of getting it out of your system is highly effective, especially when you consider the constraint of time.

Given how tiny my blog audience got over the last 3 years, I considered moving to Medium as a way to revitalize my readership though social connections. I quickly discarded the idea; no amount of perks can convince me to write on a closed platform.

With that out of the picture, I had to figure out whether I want to resume from where I left off or start from scratch. To get the SEO benefits of the former and the freedom of the latter, I decided to move the old content to a new home and set up redirects from the old one. Having total control over your data always pays off.

It feels good to be back.

Twitter Client Showdown: Round 2

hello@redalemeden.com (Reda Lemeden) — Mon, 13 Feb 2012 15:38:51 +0100

It has been almost a year since the original showdown pitting the user interfaces of the Twitter official client and Tweetbot. Since the latter got a major update last week, it is a good opportunity to revisit the Twitter client landscape on iOS.

For starters, here is a quick summary of the simplified HIP model used in this showdown:

Touch interactions are assigned a value based on the precision and time required to execute them. Single taps take in average 165 milliseconds, while double taps and swipes take 350ms and 400ms respectively. The single tap is given a nominal value of 1 and will serve as the base unit of other interactions. For instance, assigning the value of 2 to a swipe means that it’s twice harder to execute than a single tap.
A task is a chain of user interactions with an end goal. The effort required to achieve a certain task equals the sum of the individual values of each interaction involved. The lower the sum, the more efficient the interface.
Typing time is zeroed out.
Only the shortest routes were used (lowest scores).

For long-time readers, here is what’s new:

Here comes a new challenger: Twitterrific.
User flow is taken into account this time by adding the interactions required to take the user back to the main timeline in each task.
The interaction scores have been revised since. Swipes and double taps call for twice the effort required by single taps. Triple taps are the most taxing in terms of precision, long presses in term of execution time.
The tasks have been divided into two main groups: basic and advanced.

The new scores used in the test are as follows:

Interaction	Value
Tap	1
Double tap	2
Swipe	2
Triple tap	3
Long tap	2.5
Multi-option prompt	0.5

Basic tasks

Task	Tweetbot	Twitter	Twitterrific
Compose a Tweet	2	2	2
Open a link	2	4	2
Reply	3.5	4.5	3.5
Retweet	4	5	4
View conversation	2.5	3	3.5
Favorite a tweet	2.5	3.5	2.5
Follow user	4	3.5	3.5
Unfollow user	4	6	5
Total	24.5	30.5	26

Tweetbot has clearly the upper-hand even though little has changed since the initial release. In contrast, the redesigned interface of Twitter 4 forces the user to navigate constantly back and forth between the main timeline and individual tweets, resulting in a less fluid experience; opening a link in the official client and coming back to the timeline takes twice as many taps as the other third part clients. Twitterrific lands very close to Tweetbot but does a better job in terms of consistency and ease of use: all primary tasks can be carried out using only single taps.

Advanced tasks

Task	Tweetbot	Twitter	Twitterrific
Reply all (MMT)	5	5.5	3.5
Reply one user (MMT)	5	4.5	8.5
Send a new DM	7.5	8.5	7
Reply to DM	5	8	3.5
Compose a tweet with # and @	5	5	5
Report a user	5.5	6	6.5
Delete a tweet	4	4	4
Switch time-lines	2.5	3	3
Total	39.5	44.5	41

Tweetbot still comes out ahead of the official client, and barely ahead of Twitterrific. Tapbots’ popover implementation of account switching contrasts heavily with the 2 layer deep navigation required to do the same task in Twitter 4. Twitterrific does direct messages best, despite the 2 penalty points tied to the impossibility of sending a new DM without resorting to the obscure trick of adding a lowercase “d” to the beginning of the tweet.

Verdict

Task	Tweetbot	Twitter	Twitterrific
Basic	24.5	30.5	26
Advanced	39.5	44.5	41
Total	64.5	75	67
Total (Uncalibrated)	61.5	76	66
Previous Total	71.0	68	74

Tweetbot wins. Twitterrific closes in second and Twitter 4 lands third with a significant margin. The uncalibrated new scores¹ and the old scores were adde for comparison purposes. Of the three, only the official client regressed.

The detailed methodology and results can be viewed in this spreadsheet.

The uncalibrated scores were calculated using the original interaction cost values. ↩

2011: A year in Interface Design

hello@redalemeden.com (Reda Lemeden) — Sun, 01 Jan 2012 06:51:32 +0100

This is a summary of what happened in the world of interface and interaction design in 2011.

Desktop Identity Crisis

Following a series of leaks, Microsoft finally unveiled Windows 8, pitching it as a “no compromise” operating system that brings the best of their desktop and mobile offerings. The typography-centric design language that they perfected in recent years, Metro, will in all likelihood become their bread and butter in the consumer market and will remain a hot topic for years to come.

Meanwhile, Apple was busy shipping Lion, a milestone update that brought multi-touch gestures, native fullscreen support, and other iOS-inspired interface elements to the desktop OS. They also made sure to upset legions of users by changing the scroll paradigm to match their mobile implementation. Mac third-party apps are coming in all sorts of flavors, and the somewhat unified look and feel of yore gave place to a hodgepodge of visual styles and design patterns: popovers, pull-to-refresh, icon-based tab navigation, monochrome icons, you name it.

After several attempts to make a dent in the social space, Google finally decided to get its act together and build a design-driven product that can potentially dethrone Facebook. Led by Andy Hertzfeld, a prominent member of the original Macintosh team, Google+ has indisputably introduced some clever interactions such as circles, the group management interface. The refreshed visual style they deployed on Google+ already started seeping into other flagship products.

Facebook retaliated by introducing one of the most radical UI changes in its recent history, the profile timeline. On the mobile front, they managed to ship the eagerly awaited iPad app as a universal package that uses and abuses vertical tab navigation. Overall, the mobile apps look significantly better thanks to the recent design talent acquisitions; whether they work and feel as good is a whole other story.

Twitter overhauled their interface in an attempt to make it less intimidating to new users and more accommodating to advertisers. They also ended up ditching swipe gestures from their iPhone app as the last UI vestiges of the original Tweetie app acquired a year earlier.

Speaking of mobile apps, Path has managed to steal the spotlight from major social players by releasing a completely revamped interface that showcases some playful interactions and experimental design patterns.

Honorable Mentions

Web, Native,or Hybrid?

The bi-polar tone of this pointless debate has given place to another discussion about the UX implications of Web views, a new hybrid technique that involves displaying Web pages within native containers. Even though this approach garnered widespread adoption by large companies such as Google, Facebook, and even Apple, it has yet to prove itself by curbing the user experience inconsistencies it entails.

Gestures vs. Buttons

As touch screens are in the process of becoming the prevalent form factor, the transition to gestural interfaces is dividing the design community. As users, our interaction mental model is currently in a limbo state; we can hardly keep up with the overwhelming number of new interactions that we have to deal with on a daily basis. As designers, striking the balance between ease of use, memorability and discoverability is becoming increasingly hard in the lack of industry-wide standards.

The question is no longer whether a radical shift in our field is underway, but rather where it will be taking us in the years to come.

Goodbye 2011, welcome 2012.