Tag: Coding

  • The Relationship Between Design and Code

    Helen West (a.k.a. my Mum) has run a jewellery business for my entire life. She designs and makes individual pieces and sells them through her retail store. If you were to visit her workshop you’d find a wonderful array of tools and machines, but she didn’t decide to become a designer so that she could bend metal or hammer intricate patterns into a piece of silver all day. Helen’s a jeweller because she wants to express her creative ideas in the pieces she makes. Her satisfaction is not found in the swing of a hammer, but in the creation of an object that brings joy to it’s owner.

    That said, Helen has a deep understanding of her tools. It’s a requirement in order to bring her ideas to life. She needs to know which set of pliers to use to bend the metal in just the right way, or which technique will allow her to create the finish she’s after.

    I think the relationship between design and coding is very similar. 

    Code is merely the tool I use to bring my ideas to life. I don’t draw pleasure out of writing code all day. My satisfaction is found in designing and building something that’s more useful than that which came before it.

    Not all designers want to bring their designs to life themselves. That’s okay. It doesn’t make them a “bad” designer, they just need to find someone they can trust to do that for them. 

    I’ve worked with some excellent designers that don’t code. I sometimes wonder if the absence of coding skills actually frees these designers to create more innovative products. Due to their limited knowledge about todays tools, they are not constrained by their limitations. They often create designs that force our tools to evolve. Of course, designers that code can do this too, it just take a little more conscious effort to break free of these constraints.

    So should designers code? 

    Learning to code is a necessity if you want to bring your designs to life yourself. If you work with a great developer who you trust to respect your design decisions, it’s okay to delegate the coding to them.

    Some jewellers design and make everything themselves, others hand off their designs to skilled craftspeople who bring those designs to life. Either approach is okay, it just depends on how you want to work.


    Caveat: When I talk about coding in relation to the “should designers code?” question, I’m referring to interface design and frontend development (HTML, CSS, and JavaScript). Software engineering and backend development are specialised fields that I don’t think every designer needs to understand in depth.

  • Choosing the Best Client-Side Storage Technology for Your Project

    With all the different client-side storage options available today, it’s easy to get confused about which one is best suited for your project. In this post I’m going to take you through the most popular client-side storage technologies; highlighting their usage, benefits, and drawbacks.

    Let’s get started.

    Cookies

    Cookies are small text files stored in the user’s browser. Each cookie consists of a simple key/value pair which gets sent to your server with every HTTP request.

    There’s two main types of cookies. Cookies that only exist for the lifetime of the user’s session, and permanent cookies that exist for a set amount time. Once expired these permanent cookies get deleted by the browser.

    It’s also possible to use a special type of secure cookie that is only sent to the server if a secure connection is present. For example, when a website is served over HTTPS.

    // Create a cookie (on the client-side).
    document.cookie = "name=Matt West";
    

    The main advantage to using cookies is that they’re well supported by browsers. Cookies have been around a long time, and therefore it’s unlikely that your application would encounter a browser which doesn’t support cookies. Keep in mind however, that the user can explicitly disable support for cookies in their browser.

    A drawback of using cookies is that you’re limited to storing a small amount of text data (around 4K per cookie). This is something to bear in mind if you’re building an application that handles a lot of client-side storage.

    Another drawback is that cookies are sent along with every request made to the server. This means that the more cookies you have, the longer it will take for a request to complete, as the browser has to send all this extra data to your application.

    Cookies are best used for storing small amounts of data like tracking IDs for analytics software, or authentication tokens to monitor whether a user is logged into your application.

    localStorage and sessionStorage

    The localStorage and sessionStorage APIs are similar to cookies in that they allow you to store simple key/value pairs on the client. However, they conquer many of limitations that developers experience when using cookies.

    As with cookies, you have the ability to control whether the data should be stored permanently, or only for the user’s current session. Any data stored using the localStorage API will remain on the client until deleted, whereas data stored using sessionStorage is cleared out at the end of the user’s session.

    // Add data to localstorage.
    localStorage.setItem('name' 'Matt West');
    
    // Retrieve data from localStorage.
    var name = localStorage.getItem('name');
    

    Data stored in localStorage is not sent to the server as part of the request payload. It’s the developer’s responsibility to transfer data to the server through query parameters or POST data. This means that using localStorage rather than cookies can help to reduce request times, and therefore increase the overall performance of your application.

    Using localStorage also gives you access to more storage capacity. The exact amount of storage varies between browsers, but you can generally assume you’ll have access to at least 2.5MB.

    As with cookies, you’re limited to storing text data when using localStorage. Of course you can get clever and start converting objects and arrays to JSON strings and then store that. However, you will better off using IndexedDB if you need to store structured data sets. (more on IndexedDB in a moment)

    The added freedoms given to localStorage and sessionStorage make them a great alternative to using cookies. While some older versions of IE (7 and below) don’t support these APIs, most browsers do.

    If you just want to store simple key/value pairs, localStorage is the best option available right now. It’s great for storing things like names and emails from contact forms. Allowing you to pre-fill those fields if the user views the form again.

    Find out more about localStorage

    IndexedDB

    IndexedDB is the power-house of client-side storage. It allows you to store structured data and then perform queries against those datasets.

    This added functionality comes at a price however. The IndexedDB API is complex and can be daunting to those just starting out.

    Browser support for IndexedDB isn’t quite as good as that for localStorage. Safari only just added support in version 8 (which is currently only available with the Yosemite beta), and Internet Explorer has limited support for the API.

    IndexedDB is the way to go if you’re building an application that needs to store structured data. Just be aware of the steep learning curve when you’re getting started.

    Find out more about IndexedDB 
    View a demo app

    Introducing localForage; The Best of Both Worlds

    Before we end, I want to run through another option you have when working with client-side storage.

    The wonderful folks at Mozilla have developed localForage, a handy little library that aims to take the pain out of client-side storage.

    The localForage API has the simplicity of localStorage but gives you access to all the benefits of a complex API like IndexedDB. Behind-the-scenes, localForage checks to see which storage technologies are supported by the user’s browser, and then chooses the one that offers the best functionality.

    // Storing data.
    localForage.setItem('name', 'Matt West');
    
    // Retrieving data.
    var name = localForage.getItem('name');
    

    The API mirrors that of the localStorage API with regards to its methods and properties. The key exception being that you can store complex data types like arrays and objects (hurray!). Of course you’re still bound by the same limitations on storage capacity that are imposed on the underlying storage technology.

    // Storing an array.
    localForage.setItem('users', ['Matt West', 'Joe Balochio', 'Fred Smith']);
    

    Using a library like localForage abstracts away the complexity of doing client-side storage, so you can focus on building a great application.

    Find out more about localForage 
    Download localForage

    Summary

    In this post we’ve looked at some of the different client-side storage technologies that are available to you when building web applications. You should now have a better idea of the benefits and drawbacks of each, and when to use on over another.

    If you’re still unsure about which technology is best suited to your project, post a comment below with some details about what you’re working on. I’ll jump in and help out the best I can.

  • Registering Protocol Handlers to Intercept Special Links

    A cool (and somewhat unknown) browser feature is protocol handlers. These give you the ability to register your web application as a handler for protocols like mailto or webcal. Then whenever a user clicks a link with the specified protocol, they’re sent off to your app to complete some action.

    Of course you can’t just override the user’s current preferences. They first have to tell the browser they want your application to handle certain protocols.

    Once you’ve registered a protocol handler, an icon will appear in the address bar when the user visits your app.

    User permissions dialog for protocol handlers.

    Clicking this icon shows an option to set your application as the default handler for the specified protocol. Once the user clicks allow, you’re all good to go.

    Registering a Protocol Handler for Your Web App

    So how does this all work?

    To register a protocol handler you need to use the navigator.registerProtocolHandler method. This method isn’t supported in all browsers yet so you’ll want to do a quick check to see if it’s available first.

    if ('registerProtocolHandler' in navigator) {
      // Yay! The user has a decent browser.
    } else {
      // Seriously, quit using IE already.
    }

    The registerProtocolHandler method takes three arguments:

    • protocol – The protocol that you want to handle (for example mailtotel, or webcal)
    • url – A URL within your application that can handle the specified protocol.
    • title – The title of your application.
    navigator.registerProtocolHandler(protocol, url, title);

    When a user clicks a link with the specified protocol, the contents of the links href attribute gets passed to your application through a URL. You can specify where in the URL you want this data to feature using the %s placeholder.

    For example, the Gmail web app registers a handler for the mailto protocol. Once activated, whenever a user clicks a mailto link they get sent to the compose window. Gmail then uses the email address from the href attribute to pre-fill the To field in the compose window.

    Here’s an example of how you could create the same behaviour:

    navigator.registerProtocolHandler(
      'mailto',
      'https://mail.google.com/mail/?view=cm&to=%s',
      'Gmail'
    )

    Limitations and Caveats of Protocol Handlers

    An important caveat to note is that the browser sends the entire contents of the href attribute to your app. This includes the protocol, so you’ll need to clear out that out before doing anything with the data.

    You need to register your protocol handler from the same domain as the one specified in the URL argument.

    You can only send text, as the data gets transferred via a URL.

    The communication between the sender and your application is one-way. This means you can’t pass a message back to the sender to notify them you’ve taken a certain action.

    Creating Your Own Protocols

    Handling mailto links is useful, but you also have the ability to create your own custom protocols too.

    You can define pretty much any name for your protocol you’d like as long as it starts with web+. This helps to differentiate custom protocols from standardized ones.

    Let’s take a look at an example of a custom protocol.

    On your travels around the internets you may have encountered these ‘tweet me!’ callouts designed to make it easier for people to share key points from blog posts. You could use protocol handlers to do something cool here.

    Thanks to Boagworld for the example.

    Say we created a custom protocol, web+tweet, that takes some text data and sends the user off to compose a tweet on twitter.com.

    navigator.registerProtocolHandler(
      'web+tweet',
      'https://twitter.com/intent/tweet?text=%s',
      'Twitter'
    )

    Having this custom protocol makes it super easy for a website owner to create special tweet links. I don’t know about you, but I can never remember the twitter share URL without having to look it up.

    <a href="web+tweet:You should definitely tweet about this post">Share the love</a>

    Of course this approach is flawed. For it to work, every twitter user would need to allow the twitter website to handle the web+tweet protocol. This just isn’t realistic.

    Custom protocols have a purpose within some applications, but don’t expect others to adopt your protocol. The web is an open ecosystem with a wide array of recognized standards. Stick to them whenever possible.

    Browser Support for registerProtocolHandler

    Protocol handlers aren’t exactly new. The registerProtocolHandler method has been around since Firefox 3 (circa 2008!). Internet Explorer and Safari are the only two holdouts.

    • IE – Not Supported
    • Firefox – 3+
    • Chrome – 13+
    • Safari – Not Supported
    • Opera – 11.6+

    Summary

    Now you know how to register protocols handlers for your web application. Useful stuff if you ever find yourself building a web-based email client or calendar.

    Be careful with those custom protocols though, there’s times when they can come in handy, but don’t reinvent the wheel. Use standardized protocols whenever possible.

  • Greatest Hits (so far) From The Treehouse Blog

    After finishing HTML5 Foundations I was asked if I’d like to start writing for the Treehouse blog. Naturally I jumped at the opportunity and started formulating ideas for blog posts. That was November 2012.

    Over the past year (and a bit) I’ve written more than fifty posts for the Treehouse blog so I thought I’d post a list with some of my favourites. Not all of these have done well by traditional metrics, but I really enjoyed writing them.

    1. Speeding Up Page Load Times
    2. Using Web Workers to Speed-Up Your JavaScript Applications
    3. Implementing Native Drag and Drop
    4. Working with Shadow DOM
    5. Getting Started with Grunt
    6. Building a Synthesizer with the Web Audio API
    7. An Introduction to WebSockets
    8. An Introduction to The Page Visibility API
    9. Building Multi-Touch Web Applications
    10. Using Emmet to Speed Up Front-End Web Development

    I look forward to writing the next fifty 🙂

  • The Ben & Fitz Show: Essential Viewing for Web Developers

    When I was first learning to program I submersed myself in Open Source as a way to improve my coding chops whilst at the same time learning how to work effectively with other programmers. This was mainly down to the influence of two developers, turned managers at Google. Brian Fitzpatrick (“Fitz”) and Ben Collins-Sussman.

    Ben and Fitz have strong roots in the Open Source community and worked on the team that brought Subversion into the world.

    Over the past 5 years Ben and Fitz have given a number of talks about how to effectively manage Open Source projects and how to play well with other developers. Watching these talks on YouTube really inspired me to become a better programmer, and a better team member. Everyone that works on Open Source projects, or just works with other developers in general would really benefit from watching some of theses talks. I’ve put together my favourites here.

    Welcome to the Ben and Fitz show.

    Open Source Projects and Poisonous People

    The Joys of Engineering Leadership

    Do you Believe in the Users?

    The Myth of the Genius Programmer

    Programming Well with Others: Social Skills for Geeks

    The Art of Organizational Manipulation

    Team Geek

    Ben and Fitz recently wrote a book called Team Geek that embodies a lot of what they talk about at conferences. It’s a great read and I would definitely recommend picking up a copy.

  • State of The Browser 2012

    Yesterday I got up early and headed down to London for State of The Browser 2012. The event was really great and I thought I would just summarise some of the thoughts from the main talks here.

    Web vs Native: it ain’t over ’til it’s over

    Michael Mahemoff (@mahemoff)

    Michael gave a great talk about how native apps still dominate their HTML5 counterparts. Despite the great work being done by some browser vendors to open up more native services to HTML5 apps (Chrome Canary now has a Battery API) web is still way behind native and that is limiting the scope of what web developers can achieve.

    The talk also focused on the challenges surrounding UI, offline and background processing that arise when building HTML5 apps. These issues need to be resolved quickly if HTML5 is going to be a real competitor to native apps.

    The slides can be found here: http://prez.mahemoff.com/state-native/#/

    No App is an Island

    Paul Kinlan (@paulkinlan)_

    Paul’s presentation ran with the theme that web apps should be able to talk to each other without the need for developers to write loads of code. This follows on from the work that Paul is doing on Web Intents.

    Android developers don’t have to worry about creating integrations to share content, they simply fire a share intent and the OS takes care of the rest. Browsers should be doing this and later on in the Q&A all of the other browser representatives admitted that they recognize this as a problem and are working on solutions.

    I personally follow Paul’s vision of an interconnected app ecosystem and really hope that Web Intents (or an equivalent) makes it’s way into browsers soon.

    The Web as it Should Be

    Martin Beeby (@thebeebs)

    Unfortunately Martin’s presentation was plagued with all sorts of technical problems but hats off to the guy as he still managed to power through. I was interested to see what Microsoft is doing in the web space so it was a shame the demos didn’t work.

    Martin spoke about Microsoft’s vision for the web and how they are pulling web technologies into the development environment of native app developers in Windows 8. This means that web developers will be able to use their existing skills in HTML, CSS and JS to create ‘native’ apps for Windows 8. The Microsoft engineers have created a JavaScript library for interacting with native APIs, which is awesome! I think Google are working on something similar for Android.

    Overall the fact that Microsoft seem to have stepped up their game within the web space is very encouraging. But sorry folks, still no plans for WebGL 🙁

    Broken HTML5 Promises – Are we ‘appy?

    Chris Heilmann (@codepo8)

    Chris’ talk focussed on were HTML5 is today and what we have got left to do in order to really give native apps a run for their money. He spoke about his experiences at the recent Mobile Web Congress in Barcelona and how many of the execs he spoke to were more concerned about getting short term wins than building meaningful apps.

    It’s sometimes easy to forget that there is still a lot of work to be done on HTML5 and a lot of this work is convincing decision makers in businesses that HTML5 is a viable option when it comes to building apps.

    Chris also mentioned the Boot to Gecko project were Mozilla are creating a phone OS that consists of a browser running directly on top of a Linux kernel (+ drivers of course). I hadn’t heard about this before but it looks really awesome, I can’t wait to get my hands on a demo device.

    Summary

    All round it was a rather good day out. I’m interested to see what will be happening with web technologies in Windows 8 going forward and how the web vs native battle will play out over the next year or so.