BIO

‘Head of Engineering’ at Huddle – Together with the Principal Engineer the Head Of Engineering helps define quality software practices and validate the frameworks used by Huddle covering front end web site development, back end services and APis, and the client applications for iOS, Android, Windows and OS/X. Responsibilities include recruiting and leading the development teams, managing external contractors and liaising with the product and sales teams on product strategy to maximise commercial opportunities.

— TOPIC #1 —

"Don't Make Me Feel Stupid" - A. User

If every developer had read Alan Cooper’s book, “The Inmates are Running the Asylum”, we would have a lot less crappy software in the world.

In this UX orientated talk we’ll focus on how anything we design, physical or software, should not cause the user to be made to feel stupid. It’s a simple rule and yet frequently ignored.

This will be a subjective look at UX, from poor design in the physical environment, to some of the common pitfalls developers encounter and that can be easily avoided once you consider how the end users will interact with your software. We’ll not only have examples of bad UX, but highlight some really good UX decisions to provide an idea of what you might do with your own applications

You won’t leave the session being a UX expert and none of this will bring about world peace, but it sure would improve a lot of people’s lives when they interact with your software.

Session Keywords

— TOPIC #2 —

Give It a REST – Tips for Designing and Consuming Public API’s

In the past five years at Huddle we’ve been updating out public API to be more restful, more tolerant, and to handle the move from a monolithic application to one based on microservices with async operations.

We’ve also created clients for web, iOS, Android, Windows and OS/X that consume that same API and experienced some of the same pain as our customers when we have taken a wrong turn.

It’s not been easy and it’s time to share the knowledge of the real-world problems of maintaining a useable API that keeps everyone happy (some of the time).

Rather than describe the principles of REST and HATEOAS we’ll examine everyday issues, best practice for both creators and consumers, and maybe highlight some gaffs along the way.

Session Keywords