As I mentioned in this morning’s post about Medium, it’s important that Micro.blog-hosted sites can have their own domain name. Some people use their microblog to supplement an existing web site. Others use Micro.blog itself for hosting their full web site, because the focus on short posts makes the site easy to update.
Today we’re introducing a new feature for hosted microblogs: custom web pages. These can be used for expanded “about” pages, contact information, lists of current projects, essays, or whatever you want to write about on your web site. Micro.blog pages use Markdown and are automatically included in the navigation for your site.
Here’s a screenshot of an example page being edited:
If you have a Micro.blog-hosted site, check out the pages list under Account → “Edit Domains & Design”. Enjoy!
Jared Sinclair writes about iOS 7 as a squandered year for third-party developers:
“Fast-forwarding a year, the effect that iOS 7 has had on third party development is disheartening — which sounds like a fatuous thing to say, since there have been so many well-liked redesigns over the past year. But that’s the rub: the vast majority of third-party developers’ time has been spent redesigning and reimplementing apps to dress the part for iOS 7.”
I agree with Jared that it was a sort of lost year for app features, but Brent also has a point:
“Jared argues that iOS 7 wasn’t urgent, that evolution rather than revolution would have been fine, since customer satisfaction was extremely high with iOS 6. In retrospect I agree, but were I at Apple I would have argued that the situation is like tech debt — UI debt — and it’s best to deal with it quickly, completely, and early.”
They had to deal with it all at once because UIKit’s look and feel didn’t really evolve the same way Mac OS X usually does, a little each year. Even Aqua, the most dramatic change ever to the Mac’s UI, was fairly straightforward for developers to adopt; if you stuck with consistent Mac controls, you got a lot for free. There was very little of that kind of consistency on iOS because developers frequently built their own custom UIs which had to be thrown out when iOS 7 happened.
Michael Jurewitz wrote a great post last week on minimum viable products:
“As you look at your products and how you make them remember these key points. You don’t need all the features under the sun. You don’t need technical excellence (assuming you also avoid technical debt). You need to solve a worthwhile problem in a delightful, thoughtful, and simple way.”
What he’s saying is it’s okay to be limited, but make that limited part totally polished. Cutting back features doesn’t mean you also cut back on quality. It reminds me of the quote from 37signals: “build half a product, not a half-ass product”.
This is good advice that I need to take to heart. I don’t have much problem shipping. But my apps often have some rough edges at 1.0.
Also don’t miss Jurewitz’s great 5-part series on App Store pricing. I’m linking to Michael Tsai’s summary here, since it provides nice quotes and links to each part in the series. I saw the talk that these blog posts were based on twice, at Çingleton and NSConference, and this has to be the best translation of a conference session into blog form I’ve ever seen. Not to be missed.
“Lukas Mathis writes”:http://ignorethecode.net/blog/2010/02/02/removing-features/ about removing features:
“You don’t _have_ to try to please everybody and eventually create an application that is liked by nobody. In fact, since your users are in all likelihood in a situation where they can switch applications easily, and since they probably are not locked in by the need to open a specific file format in its native application, it might be a really bad idea for you to go down the ‘simply add up all the requested features’ route of application design.”
He also links to “my Wii Transfer survey”:http://www.manton.org/2009/07/wii_transfer_survey.html, so I thought I’d post a quick follow-up. I eventually did remove a feature, and the survey to customers served as a nice sanity check that the feature wasn’t heavily used. The interesting part, to me, is that the feature I removed was the entire 1.0 product for Wii Transfer. Literally everything that 1.0 did is now gone.
It’s been two weeks so far without any complaints. I like to think that it removes a distraction from the app — one less place in the app that could lead the customer down the wrong path. And hopefully it’ll eliminate a tiny part of my support load, as no one can ask me questions or have problems with that feature again!
On an internal company mailing list I once wrote:
“Products that don’t exist yet have a way of attracting new features because everyone sees the potential in something that has no form”.
I was talking about resisting the urge for everyone on the team to pile on their favorite features before 1.0, but I think this applies to apps with a minimal design as well. A simple app shows promise. A cluttered app with too much going on looks “done”, and sends a message that it is mature and maybe going in a different direction than what the user wants. In that way, the irony is that removing features (the wrong features) may actually make an application more appealing to new users.