Avoid features vs abandoning them

I stumbled on an article from Matt Galligan about the initial versions of Cir.ca, a news aggregator app from a few years ago that recently closed up.

So the article talked about many of the design ideas they had, and the struggles they worked through before changing or abandoning some ideas.  This is an example

I don’t think it’s just me, but certainly types of people *like* me, that would immediately look at that and say “it can’t realistically be done”.  There’s too many variations of image sizings/croppings/ratios that would prevent decent text overlays to make this anything near automatable.  Without automation, this means every item would need human input/work to get that visual aesthetic ‘just right’.

I’ve pointed this one out not in hindsight, but in ‘present sight’ in many projects – specifically, tying interfaces to designs that were only tested with 2 images and 3 lines of content, but that are intended to support unlimited amounts of images/content – all the use cases are unable to be defined in a single photoshop file.  As the person who has to actually make it all work, you have to be able to account for all input values – headlines won’t always be 24 characters.  How do you deal with a 70 char headline?  How do you deal with user-generated photos with non-standard aspect ratios?  These questions have to be addressed, and often the best solution is extreme limiting of the input variables if ‘design’ is the primary concern.

And yet, I’ve been on multiple projects where a design like this gets approved (often by many folks) before ever letting someone who will have to implement it be involved.  When the reality hits…. the pushback on the dev/engineer is often “just make it work”.  Or “quit being negative”, or what have you.  I can only imagine how much time/money was lost/wasted on this particular issue, but also how often this *exact* problem has been played out/repeated over hundreds or thousands of app startups over the last few years.  Each team beating their head against the wall to try to implement the ‘vision’ collectively wasted thousands of hours and dollars.

In many cases, it’s better (in terms of getting to market, hitting deadlines, reducing time/money waste, etc) to avoid working on features up front vs having to abandon them later.  Convincing others of this, especially after decisions have already been made, is often a difficult task.

While certainly was not glad to see cir.ca close up, I was grateful to see Matt’s notes here.  I’m curious if anyone will actually pay heed to some of the lessons in this particular presentation and learn from them, saving themselves loads of time/money/headache.  My cynical nature expects not, because people always think their project/team/vision is more unique/special than it really is, and they’ll ‘get it right’ where others failed.

This all came about by perusing “/r/shutdown” subreddit earlier today.

Somewhat of an aside, but Matt worked with Joe Stump on SimpleGeo years back, and Joe is someone I knew from the early 2000s in Michigan before he moved on to greener pastures.  Matt also worked with Arsenio Santos at Cir.ca, and Arsenio was one of the better dev managers I’ve worked for over the years.  So while I’ve never met Matt directly, he’s a reminder to me a the increasingly small world we live in.