Is the Native Mobile App Ecosystem Worth Saving?

The native mobile app ecosystem is facing some major challenges. Some have even argued that it is in need of saving. Before we get there, though, let’s examine what the problems are. About 5 years ago, we were in the middle of a modern “gold rush” with companies eager to establish a presence in the app stores. The iOS App Store opened in 2008 and it had already reached its 10 billionth download by 2011. The Android Market (now called Google Play) reached its 10 billionth download in late 2011 as well, having launched in 2008 as well. It’s no wonder that companies felt they had to be there - even if little thought was sometimes given to what value their app actually offered. The presence was enough. Since that 10 billionth download, the app ecosystem continued to grow. This was driven in part by the fact that the mobile browser lagged far behind the ability of native apps. HTML5 was still seriously incomplete - the first working draft wasn’t even published until 2008. Adobe was pushing Flash for mobile, which would have brought the “app-like” capabilities of desktop Flash to the mobile browser, but…I don’t really need to revisit that, do I? By 2013, Apple’s App Store alone was raking in $10 billion in annual gross revenue. Yes, that’s billion with a b. Apps, it seemed, had won. So what’s changed? Please note that this article represents my personal opinion and not those of my employer, Progress Software / Telerik. No One’s Using Our App In his recent post, Alex Austin makes a strong case that the mobile app ecosystems has become over-saturated and tilted heavily towards the top 0.01% of apps. He posted a chart that illustrates this. Given the dramatic drop off, what chance does your company’s app have? As Alex says: In the past four weeks, there were 45,000 new apps submitted to the iOS App Store alone. The chances that any of them will ever break into the top 1000 are effectively 0%, and even if they did, they’re still not seeing any amount of traffic to build a successful business. This assertion is backed up by industry reports. In a recent mobile apps survey, Gartner covers how reluctant users are to installing new apps. Only 8% (U.S.) [of respondents] said they enjoyed searching for new apps. And in Comscore’s 2015 U.S. Mobile App Report, they note the difficulty in building a mobile app audience. Despite growing audiences on apps, the existing digital infrastructure makes it harder to build large audiences on apps than on the web. As evidenced, the mobile web still has 3.5x more web properties with 5 million unique visitors than apps have. As if to reinforce Alex’s point, they note that the “list of Top 25 mobile apps is dominated by the leading digital media companies and tends to concentrate within a few categories.” Add to this other recent studies that have noted that a large majority of users don’t download a single new app in any given month (it’s around 65%, according to a 2014 Comscore survey). While Comscore notes that a company’s mobile app audience tends to be worth more because they are more loyal, there are clearly many obstacles in the way of building a substantial and monetizable audience in the app ecosystem. Well-known venture capitalist Fred Wilson has discussed what he calls the “mobile downturn” since 2014. In a recent post, he noted: Doing anything in the consumer mobile space these days is super hard. I can’t think of many consumer facing mobile apps that have gained massive traction and sustained it in the past three years. Can you? In the same post discussed earlier, Alex Austin shared some ideas of how to save the mobile app ecosystem - more on that later. But first, can’t the mobile web offer an alternative? The Mobile Web to the Rescue? So if apps are hurting, does this benefit the mobile web as an alternative? Yes…and no. In a recent post discussing why the Atavist is dropping its native apps, Evan Ratliff and Jefferson Rabb note that one of the reasons is that the mobile web has finally caught up, in many respects. The situation is not the same one as in 2012. Many of the features available to native apps are now available in the browser - and it is much easier to develop once for the web than to maintain multiple native apps. Because of this, they note: The reasons for creating a native experience began to narrow. Not only was there very little we could do in a native app that we couldn’t do on the web, but the strictures of the native app environment made it nearly impossible to design well for both. And the mobile web audience is extremely large and growing. Referring again to Comscore’s 2015 U.S. Mobile App Report: A comparison of the Top 1000 Apps vs. the Top 1000 Mobile Web Properties shows a surprising result. Not only do mobile web properties have audiences that are more than 2.5x the size, but these audiences are also growing twice as fast. So if the web is nearly as powerful, easier to develop for, has a larger reach and is growing faster, what’s the problem? Well, Comscore did follow up the above stats by noting a lack of engagement by mobile web users. Average engagement has been in a steady decline since late 2014, leading them to believe that much of the growth is what they call “drive-by traffic.” The other big problem with the mobile web is that, as I’ve discussed in detail before, the mobile web suffers from performance issues and poor monetization capabilities - these are somewhat related as the performance problems are often caused by the attempts to monetize. This has led to the rise of mobile ad blockers, which, while apparently very effective in improving performance, are expected to cost businesses upwards of $22 billion in revenue this year alone. Yes, that’s billion with a b. So There’s No Hope Then? So, at this point we’ve established that the native mobile app ecosystem is potentially broken and the mobile web doesn’t currently offer an easy, clear-cut alternative. What can we do? Let’s turn back again to Alex Austin’s article. He offers a variety of potential solutions to fix the mobile app ecosystem including a better discovery system and, essentially, automatic download/install of apps via intents. He ends with the assertion that “something must be done.” But must it? I agree that there is a problem with the native mobile app ecosystem. In fact, I’ve been arguing this on a personal level for years. Before I go further, I will reiterate that this is my personal opinion and does not reflect those of my employer (i.e. Progress Software or Telerik). Ok, now that that’s out of the way, I can say that I think the bigger issue is that most apps suck. That’s Right, I Said Most Apps Suck Yes, I am being hyperbolic here but let me explain. First, apps have to overcome series of inherent issues such as: Apps require a download and install process, even if we link to the app via intents. This isn’t necessary on the web. Apps eat up space on my device - sometimes needlessly large amounts when you combine the application, cache and data. Web apps use little to no permanent storage (with minor exceptions). Many apps can hurt the performance and battery life of my phone by running background processes. Web apps do not (and despite some claims, ads don’t kill your battery and mobile web ad blockers have been shown to offer minimal improvement on battery life). Apps are noisy (and can be annoying) by design and by default. Managing the mess of app notifications is such a pain that we’re willing to pay $350+ for a separate device whose primary benefit is decluttering app notifications. Apps require constant maintenance by the user via updates and app store approvals. Plus it can be difficult, as an app creator, to get your users to update. The web is always running the latest release, no intervention needed. None of these problems are dealbreakers and some are more prominent on one platform versus the other. And a good app can make all these issues seem trivial. However, it is important to keep in mind that apps don’t inherently offer something of value. The value is what you build into it. Simply being in the app store does not make your app worthwhile to consumers. Let’s look at Comscore’s list of the top 25 apps (i.e. the apps that eat up over 99% of all usage): Source: Comscore Many, if not most, of these apps could arguably run equally well on the web and offer equivalent, or nearly equivalent, functionality. Heck, a number of these are simply “appified” versions of the web site. However, all of them have the brand power to push them to the front of the line regardless (or even come pre-installed on many phones). The point is, unless you have a massive global brand to fall back on, the only way for your app to stick out in a crowded marketplace is to truly focus on the needs of your users. Better monetization and establishing an app store presence are company problems, not a consumer ones, and not reasons to build an app in and of themselves. If you already have an app and feel the need to improve adoption via an app install interstitial, it’s very likely that you haven’t given enough thought as to why your app exists in the first place. Instead of trying to force your web users into your app, focus on making your app more appealing by making it useful. Gartner’s advice in their recent report speaks to retention, but, in my opinion, applies equally to gaining new users: Focus on creating richer, more immersive and personalized app experiences for your apps users to keep them coming back. I Did Also Say “Most” I should emphasize that I am not claiming all apps are bad or apps are bad by nature. In marketplaces that each have over 1.5 million apps, there are probably thousands of fabulous apps. However, the large number of bad apps are crowding out the good ones, making them hard to find or identify. Apps also have some innate benefits. For example ,most of the apps I have installed don’t really offer a ton of functionality over their web counterparts, but I use them for the one-click convenience the home screen icon offers or because, in some cases, their push notifications matter to me (Slack for instance). These benefits are not without value. These are areas the web needs to catch up. The one-click convenience does not have to be solely the domain of native apps. And push notifications on the web are coming (and in some cases, they’re already here). The Native Mobile App Ecosystem Doesn’t Need Saving Native mobile apps don’t need to be saved because they aren’t dying. This pain the ecosystem seems to be going through is not a pain of injury but one of healing. It is a pain caused by misuse - by filling the app store with thousands of apps that don’t need to exist. It is a pain that, I believe, will cause companies to move from saying “We need a mobile app” to asking “Why do we need a mobile app?” Answering this question gets at the real value your app intends to bring for the consumer/user. There’s a famous scene from the Seinfeld episode named “The Pitch” where George Costanza is pitching his show about nothing to a TV executive: GEORGE: The show is about nothing. … RUSSELL: Well, why am I watching it? GEORGE: Because it’s on TV. RUSSELL: (Threatening) Not yet. For too long, many companies used the George Costanza line of reasoning for their apps - why would anyone want to download this app? Because it’s in the app store. And too many apps were about “nothing” in the sense that they didn’t focus on the value they intend to offer by being an app beyond just claiming a spot in the app store or offering the company that created it an easier route to monetizing than the web offered. The current state of the native app ecosystem is forcing companies and developers to come to grips with what value our native apps offer over the web before entering an already overcrowded market. The result, I hope, will be fewer but better apps. Meanwhile the current state of the mobile web is forcing us to fix the issues we’ve let fester because of our over-reliance on native apps to solve the ills of the web - namely performance and monetization. The result, I hope, will be a mobile web that better meets the needs of both consumers and companies. Yes, both ecosystems need some fixing but both will survive. And I believe both will be better for their suffering.

Posted by on 16 November 2015 | 11:00 pm

Some Advanced Jekyll/Liquid Template Techniques

Generally speaking, Liquid templates for Jekyll are pretty easy to create - Liquid is a powerful templating tool and offers a large number of helpers and formatters to get complex tasks done. However, recently I had the opportunity to build a site that required me to use some techniques I’d never needed before with Liquid and Jekyll. The home page had a number of repeating sections that listed the content for each category of content. If there was no content, the section shouldn’t show. More importantly, each section was essentially the same except for some category metadata and styling. Rather than repeat the same code for each section, I decided to use includes - but this required some creative workarounds to make the styling show. In this post, I’ll show some of the techniques I used. I am not entirely certain that these are necessarily “best practices,” but since there wasn’t a lot of information I could find around the web on this, I thought it might be worth sharing. (And if you have better ways of solving these problems, please share.) Determining If a Category Has Posts (and How Many) This one is actually pretty straightforward. Each category has a size property which you can use. {% if site.categories.categoryname.size%} <!-- do something --> {% endif%} Obviously, replace categoryname with the actual category you used for your posts. Don’t worry, it won’t error if the category doesn’t exist. Now, I suppose you could leave the .size off assuming that if the category doesn’t exist, that is because it contains no posts, but this works just as well (and reads easier perhaps). Assign the Value of a Variable In this scenario, I had a variable that would have the current category. Assigning a variable is easy. Liquid has an assign keyword for this purpose. {% assign categoryname = 'foobar'%} Some examples claimed that you could not reassign the value of a variable once initially assigned. I didn’t find this to be the case. However, you can, alternatively, assign a variable with capture. {% capture categoryname %}foobar{% endcapture %} Using a Variable with an Include There’s really nothing special to do here. If the variable is assigned, you can simply use it within any include thereafter. (Note: I tried using the with keyword to pass the variable in the include rather than assigning it each time, but couldn’t get this to work properly.) The fun part here is that the include was always the same, just the value of the variable changed. Let’s look at a small portion. {% if site.categories.foobar.size %} {% assign categoryname = "foobar" %} <section> {% include index_article.html %} </section> {% endif %} {% if site.categories.barbar.size %} {% assign categoryname = "barbar" %} <section> {% include index_article.html %} </section> {% endif %} Within that include (which I poorly named index_article.html), I can loop over the posts within that category by using the variable. {% include banner.html %} <ul class="ArticleList"> {% for post in site.categories[categoryname] %} <li> <h4><a href="{{ post.url | prepend: site.baseurl }}">{{ post.title }}</a></h4> <p>{{ post.description }}</p> <p><span class="Author">{{ }}</span> <span class="PublishDate">{{ | date: "%b %-d, %Y" }}</span></p> </li> {% endfor %} </ul> Dynamically Load Data So, remember I said that the banner changed based upon some category metadata? Well, in order to do that, I decided to place the necessary metadata items in a YAML data file under _data. Each category had the same key name as the actual post category so that I could easily look it up. (Yes, this is probably a little brittle, but remember we are talking a static site - it’s not like I’m going to push something broken live.) Let’s look at a sample of the YAML. foobar: name: "Foo Bar" description: "Foo is the best kind of bar around" logo: "foobar.png" color: "Purple" barbar: name: "Bar Bar" description: "There's no doubt that bar is the original kind of bar" color: "Orange" Notice that they don’t all contain the exact same metadata - the first has a logo but the second doesn’t. In the index_article.html code sample above I included banner.html. Let’s take a look at that. <div class="SectionHead {{[categoryname].color }}Box }}"> <div class="LogoSpot"> {% if[categoryname].logo %} <img src="{{ site.baseurl }}/images/{{[categoryname].logo }}" alt="{{[categoryname].name }}"/> {% elsif[categoryname].subtitle %} {{[categoryname].subtitle }} {% else %} {{[categoryname].name }} {% endif %} </div> <h2>{{[categoryname].name }}</h2> <h3>{{[categoryname].description }}</h3> </div> Notice that I am able to dynamically pull the category name via the variable (and even though this is an include within an include after the variable was set). Also notice that I can test if particular properties exist on the category - for example I show the logo if it exists, if not the subtitle (if it exists) and else just the category name. Conclusion Hopefully these examples are useful - I know they would have helped me. If anyone has suggestions on how I could have achieved the same results in a better fashion, please share. Also, be sure to check out my free ebook from O’Reilly - Static Site Generators - Modern Tools for Static Website Development

Posted by on 1 October 2015 | 11:00 pm

Get Started with Static Site Generators

In the early days of the web, there was no such category as “static sites” - the web was made up of static resources. This was a maintainable solution when the web was simple. That didn’t last long. Static sites had enormous limitations that made them an impractical solution for most web sites - even the relatively simple ones. More recently, however, a combination of asynchronous content, third-party services and new tools, called static site generators, have made the old skool static site both feasible and cool again. Tools like Jekyll are used to run thousands of sites across the web (including this one…though it admittedly deserves more love). But what are static site genertors? Which one of the 400 or so of them should you consider using? What types of sites are they most suitable for? These are some of the questions I aim to answer in a free report on static site generators for O’Reilly Media. I know what you are thinking - “Awesome, just in time for the weekend!” You’re right! Did I mention it is free? Also, I should note that it is free. Hopefully this report will answer any questions you may have about static site generators and help you get started in choosing one. Static Site Generators - Modern Tools for Static Website Development

Posted by on 24 September 2015 | 11:00 pm

Which Free Code Editor Is Right For You?

We live in a day and age as web developers where our biggest complaint seems to be a overabundance of free tools. In the case of code editors, there are a few prominent free ones: Atom, Brackets and, most recently, Visual Studio Code. Each editor has its own set of strengths and weaknesses. Each is backed by a large corporation - GitHub for Atom, Adobe for Brackets and Microsoft for Visual Studio Code - so obviously they will be geared towards the target audience of each respective company. Nonetheless, they are all good editors. So which one should you choose? Well, it depends. You knew I was going to say that! In my latest article, Battle of the Free Code Editors, I go into the distinguishing features of each editor and what type of developer it is best suited for. Please, check out the article and feel free to share your thoughts. A Note on Sublime I was asked numerous times after writing this article, why did I not include Sublime? After all, Sublime is, for all intents and purposes, the market leader for lightweight code editors. The article compared free editors. However, Sublime is not free! Yes, you can try it for free and, as many responses noted, use it forever without paying if you are willing to live with dismissing the prompt to buy regularly. One person even noted to me that if the author didn’t want people to use it for free forever, they’d have a different license method. I’m sorry, that’s not how this works. The author clearly states: Sublime Text may be downloaded and evaluated for free, however a license must be purchased for continued use. As I said on Twitter… It surprises me how many people seem to advocate using Sublime for free. If you think the software is great, why not pay what they ask?— Brian Rinaldi (@remotesynth) September 17, 2015

Posted by on 22 September 2015 | 11:00 pm

Picking the Right Speakers for Conferences

I have been involved in events for some years, ever since running Flex Camp Boston back in 2007 and as recently as handling many aspects of the planning, in particular the speaker lineup, for this year’s TelerikNEXT event. I’ve also served on conference committees for events like QCon New York and Fluent. In my personal experience, the hardest part of running events are getting the word out and choosing the right speakers. Arguably, choosing the right speakers can heavily impact your ability to get the word out - after all, your content is the biggest selling point of your event. Yesterday, Lea Verou posted an opinion piece saying that blind reviews for technical conferences is a broken model. You should read the full post. In summary, she believes that while the goal is to reduce bias and allow unknown speakers an opportunity, it ends up leading towards choosing “safe” topics. This is because the fear is that the more advanced or atypical topics, in the hands of the wrong speaker, could totally bomb (I’m paraphrasing - these are my words not hers). I agree with her, and while I laud the goals of making the speaker selection more egalitarian, there is simply not enough information in a typical abstract to know how successful a presentation will be as the text doesn’t indicate the speaker’s ability to communicate effectively in the format of a session (and requiring a prior session recording already starts making the process less open to fresh faces). Here’s the response I added to her post: I totally agree with this. When I ran a conference for 5 years, I was of the mind that who gave the talk was generally more important than what they were talking about. There are people whose talks I want to see regardless of what the topic is - they are engaging, thought provoking and I always come away learning something. Other people could pick the best topic and even have the best slide deck and bomb. I chose to have invite-only speakers list. That being said, I always set aside a certain amount of slots for speakers I’d never seen or who were new. The trouble with invite only events is the tendency to invite from within the same group every time. To me the best option is to have a committee that you trust and who represent a diverse set of experiences, backgrounds and views. Have this committee be conscious of efforts to be inclusive and make sure there is room for some fresh faces (even acknowledging that some of these will inevitably bomb). As you say, each method has its flaws and potential for bias, but even the blind review (as you point out) has bias, just of a different kind.

Posted by on 14 August 2015 | 4:00 am

Is the Web Really in Trouble?

This morning I published a post on the Telerik Developer Network that asks the question “What’s Wrong with the Web?”? If you read about web development at all (and apparently you do, since you are reading this), you can’t possibly have missed the long list of posts declaring that the web, as we know it, is in serious jeopardy. The main issues are: The web is losing the battle to native The web is too slow, largely due to the weight of advertising The web is too slow, largely due to the cruft of too many libraries and frameworks The web is trying to be something it isn’t (i.e. native) and adding too many unecessary features There may be more, but these are the core debates. The thing about all these debates is they are very technical - they are about how we build web apps or the underlying technology of the web. None of these debates seems concerned with what we are building. As I argue in the conclusion of my post, perhaps we’re worried about the wrong thing. Perhaps if we focused on building awesome and creative things on the web again, the answer to these problems would work itself out. I worry that web developers have become like bureaucrats, too worried the procedure of building web apps, having lost sight of the point of building them in the first place. I’d love to hear your thoughts. Please comment on the post on the Telerik Developer Network.

Posted by on 2 August 2015 | 4:00 am

The Web is Boring

When I was growing up, flying was fun. This wasn’t the kind of fun that a kid finds in simply new experiences - it was a legitimately enjoyable experience. The airport was a much less stressful place than it is today, with far less security and fewer lines. The planes seemed more spacious (though perhaps that part was really just that I was a kid). They served you food on most flights - with a real, metal fork and knife. Perhaps it wasn’t the greatest food, but wouldn’t we just love to get something, anything, nowadays? They’d even let kids go into the cabin and meet the crew, often handing them a junior crew member pin to wear. I fly more nowadays than I did back then, but flying is generally painful. The airport is stressful. The airline customer service is generally awful. There are few, if any, meals or snacks served. Flying has become something I need - for work, to visit family, to get to somewhere for vacation - not something I enjoy. Even on vacation, flying is something we power through to get where we want to be rather than being part of the vacation experience. The Web, Too, Has Lost Its Luster Much like the joy of flying, I am finally ready to openly admit that the web is no longer fun. Just like flying, I use it more today than I ever did back when it was fun, but it is purely out of necessity rather than desire. On a personal level, I use web sites to get news and to keep up with friends and family. The web is, obviously, an integral part of my work too, for news and information as well as the focus of my actual job. All of these things I need, but none of them bring the joy and exitement that the web used to bring. Perhaps you are not old enough to remember when the web was fun. If so, you may even think that it is fun. But back in the mid-to-late-90s, the web had the power to amaze us. New sites and new businesses would launch regularly and everyone had to try them out because each one seemed to bring something new and creative to the table. Sure, many didn’t survive long (and we had tons of useless accounts), but they all seemed to be part of an inexorable path towards something special - a future where the web would make our lives more enjoyable, easier and, yes, more fun. Many of us firmly believed that the web was the future of computing - who’d need a desktop or operating system when the web was eventually going to replace the need for either. That Didn’t Happen Let’s be honest. None of that ever happened. You may be thinking, “But what about my streaming movies or my streaming music or my multiplayer games? Aren’t those fun?” To which I’d say, “Don’t confuse the internet with the web.” The internet enables each of these, but they are rarely done via the web (yes, they all have web interfaces, but I’d bet the majority of people do not access them this way). There’s been a lot of talk about how the web is losing some unofficial battle for survival. Much of that has focused on the overwhelming amount of tools for web development and the way these tools are impacting the performance of the web. I am not disagreeing with those, per se, but I can say that the web was actually much more fun back when it was also horribly slow (most of us were on dial-up after all). I feel that the thing holding the web back is a lack of real, creative innovation. I read every day about new little features of the web platform, but I can’t remember the last time I read about something built on the web that really excited me. Until then, I’ll keep passionlessly reading my news and blog posts or getting my gmail and hating myself for checking Facebook for lack of something more interesting to do. Sorry, web, but you bore me.

Posted by on 24 June 2015 | 4:00 am

Tips for Writing for a Tech Audience

I’ve been writing articles and blog posts about web development and technology for a long time. The original version of this blog started in 2004, but by that time I’d already written a couple articles for the ultra-prestigious ColdFusion Developer’s Journal (it’s ok to feel jealous). However, I’ve also been editing articles and blog posts about web development and technology for a while too. It started when I was at Adobe helping to run the Adobe Developer Connection a few years ago and continued when I launched my own site (Flippin’ Awesome which is now Modern Web and not run by me anymore). I still do this on an almost daily basis running the Telerik Developer Network. All of this experience has taught me some things that I think help to make a really good (and potentially really popular) article or blog post for a developer or technology audience. In this post I’ll share my recommendations, though I should note that I’m not an expert at always following my own guidelines all the time. Have a Style It’s important to keep in mind that you aren’t writing API docs. API docs are generally dry, boring and simply stick to the facts. That’s their goal. However, an article or blog post should allow some of your personality to shine through. This helps to make the content both more relatable and more enjoyable to read. Keep in mind that your goal is both to educate and to entertain, to some degree. Some developers revert to a litany of code and explanation. It’s better to have a voice and have a story. Some things that can help: Explain why you are trying to do something, not just what you are trying to do and how you are doing it. What made you get interested in doing this? Did you have a struggles along the way? There’s no shame in admitting that you found something difficult - your readers will likely relate to the experience. Have fun with the demo! Perhaps pick something you are interested in that isn’t technical. For example. I often choose to use some cartoons I enjoy as subject matter for my demos. Know Your Audience While you should have a voice and a style, it’s important to know when it’s ok to be more or less casual in your voice. If I am writing something for my blog, I am often much more casual than if I am writing for the Telerik Developer Network or Sitepoint. If I am writing for my blog, proper grammar, punctuation and spelling are less important. If I am writing for a professional site, these become the difference between seeming like an amateur and not. You’d be surprised how people are affected by these things, even if they do not recognize it themselves. Some sites have editors who help with this, but others don’t - so don’t rely on them to correct your mistakes. Try to always have a friend you trust read through the article first - this isn’t critical for a personal blog post but even those can benefit. Even the best writers need a second opinion and there is nothing than can make your content better than a good, critical opinion. Stay on Track So many developers tend to think that every little detail is pertinent. So, they get sidetracked. Instead of traveling straight down a path, they don’t just point out the detours, but take you down them. As a rule, if the information doesn’t apply to most situations, don’t spend time on it. These are the kind of scenarios like, if you are running an old version of X operating system and want to perform special action Y, you’ll need to do this a different way - let’s walk through it. Another example is getting lost in caveats, detailing every minor exception that in all likelihood doesn’t apply to the reader. The best strategy in these cases is to simply point to the “detour” as an aside and link to the best resource to follow. Or note that there are exceptions but don’t go detailed into the full list of caveats. You may feel as though you are being somehow incomplete in your coverage, but you are less likely to lose the 90% of the readers to whom the straightforward path applies by not catering your post to the 10%. Avoid the Wall of Text There is nothing harder to read than a post that has no headers and is filled with overly long paragraphs. Adding section headers and even subheaders for long sections not only makes your article easier to read, but also makes it easier to scan - which can help the reader determine it’s value to them. Shorter paragraphs also make your content more readable and scannable. Plus, a wall of unbroken text can seem intimidating to a reader. Break up large paragraphs and, whenever possible, place key ideas into lists, which I’ve found can help drive home key points and improve retention. What Are Your Ideas? Hopefully you’ve found these ideas helpful. Do you have any strategies you use to improve your writing? Please share.

Posted by on 18 May 2015 | 4:00 am

Why are Web Developers Hostile to Audio?

I like to talk and write about Web Audio. It can be a fun topic. However, most talks and demos fail to touch on anything useful. Sure, we can build drum machines and sequencers to our heart’s content, but how does this apply to 90% of the web? It doesn’t. Thus, when I speak or write about web audio it seems to draw a niche audience. However, recently I have been on a mission to talk and write about how web developers can use web audio to enhance their applications in practical and useful ways. The frequent response I get is like the one below: You gotta love social media because not only did this person make it clear he never bothered to read the article, but 5 people (which on Google Plus is like everyone) gave it a plus one. However, leaving aside those issues, why are web developers so outright hostile and dismissive to even the suggestion of using audio on the web that they aren’t even willing to discuss it or hear arguments as to how it could be useful? Let’s recap: Audio in game UI equals totally expected; Audio in mobile app UI equals acceptable; Audio in desktop app UI equals legitimate, within reason; Audio in web apps equals ARE YOU INSANE?!?! I have a theory as to why. The Legacy of Years of Misuse I expressed this In the early days of the web, we didn’t have the web audio API. What we had was site’s that got clever and used MIDI or, even worse, had some obnoxious “Hamster Dance” like audio. Then came years of Flash Intros and more useless audio. It became ingrained in web developers’ heads that audio on the web was purely a gimmick. It is such a widely accepted “faux pas” to include audio, that even the mention of carefully considering audio brings strong reactions. It’s Time to Let It Go But do we have to be held back today by the misdeeds of years ago? Sure, the web audio API can be misused. Sure, so far, we’ve mostly shown how it can be used for things like 8 bit video game music (guilty as charged) and web-based drum machines. (Not that those things are useful, even purely as excercises in having some fun with your programming skills, they are beneficial.) The point is, though, this doesn’t negate there being useful and practical ways to integrate audio into your web application. If it’s ok for every other type of application, why not the web? Unlike the commenter above, perhaps you’ll give my full article a read. I’d love to hear your thoughts on the topic.

Posted by on 14 May 2015 | 6:15 am

Jekyll Versus the Competition

On Saturday, May 2, the first ever JekyllConf was held online and featured some really prominent speakers including Tom Preston-Werner and Brandon Mathis. I had the honor of opening the event with my session comparing Jekyll to other popular static site engine options including Harp, Hexo, Wintersmith, Hugo and Middleman. In summary (and in my personal opinion of course), Jekyll is still in the strongest position of all the engines. It has the strongest community (partly evidenced by JekyllConf itself), the best documentation (not saying it couldn’t be better, but it’s better than the alternatives) and has the largest selection of pre-built templates and plugins. However, it has failed to reach much beyond hardcore developers. This is partly because of the nature of the tool - for instance, few people outside of the developer community enjoy working on the command line…in fact, most find it intimidating. Tooling for authors is weak too - Markdown is a terrible option for authors (who aren’t developers). We think of it as being so simple and easy, but that’s actually what makes it so complex. In terms of authoring, it covers a majority of use cases, but it is still very common to encounter requirements that it doesn’t meet (intentionally, since it’s goal was simplicity). Thus, when you teach an author Markdown, you need to teach them the syntax, what it doesn’t cover and HTML to handle those scenarios it doesn’t cover. This is actually more complicated than simply teaching them HTML. In my opinion, until the tooling is available to allow authors and contributors to write using the tooling they love, static site engines will remain a niche solution. This is a shame as they actually seem like the optimal solution for content focused sites and, perhaps more so, documentation sites. The good news is that there are people working on the tools needed to bridge this gap…we’ll see how this goes! You can see the full session recording below or view the full recording of the day here.

Posted by on 7 May 2015 | 6:15 am