Sarah Maddox's Blog, page 21

Introduction to API tech writing – upcoming webinar

On Wednesday February 11th, US EST (that’s Thursday here in Australia), I’m presenting a webinar about API technical writing. It’s the first in��a series on API technical writing from the Society for Technical Communication. I’d love it if you could join me online.

The role of API technical writer is exciting, rewarding, and challenging. I’ve been working as a full-time API writer for 18 months now, and I love it!

APIs are a hot topic in our field, and technical writers with the skills to document them are in high demand. Many technical writers are keen to know more about the role, but it can be hard to find information. Sometimes there’s so much information that it’s difficult to know where to start. In presenting this webinar, my aim is to give you a good idea of the role of API technical writer, and some excellent starting points to explore the world of APIs.

Details of the webinar

Title:��Introduction to API Technical Writing.

Date and time: Wednesday, 11 February 2015, at 2pm EST (GMT-5)����� that���s 6am on Thursday here in Sydney!

Duration: One hour.

Fees and registration/signup: Please refer to the STC announcement:��Part 1 in API Series: Introduction to API Technical Writing.

The session covers��the following topics:

What an API is and does.
Introduction to the role of API technical writer and our audience.
Overview of the types of developer products we may be asked to document – APIs and others.
Types of APIs, including REST APIs, other web services, library-based APIs like JavaScript, and more.
A couple of live demos of APIs that you can play with at home: a JavaScript API and a REST API.
Examples of good API documentation.
The components of API documentation, and the technical writer���s role in the creation of each component.
A��day in the life of an API technical writer.
Tips on getting started in the role.

More in the STC’s webinar series on API technical writing

Following on from my introductory webinar, the next two sessions in the STC���s series��have already been announced. In episode 2,��Ed Marshall talks about documentating Java and C++ APIs. In episode 3,��Joe Malin describes how to write effective code samples.

I hope to “see” you at the webinar!

Talking of technical communicators who write books

Many technical writers do other types of writing too. This week I had the pleasure and privilege of meeting one of them in person. Cynthia Chin-Lee is a manager in information development at Oracle, and also the author of a number of books. She made me a present of two of them – such a generous gesture.

One of the��books Cynthia gave me is��Amelia to Zora, Twenty-Six Women Who Changed the World. Cynthia is the author, and the illustrations are by Megan Halsey and Sean Addy.

Each page is about a woman who’s done amazing, beautiful, world-changing things with her life. Cynthia has managed to pack an enormous amount into just a few words about each person, with a quotation from each one. The illustrations by Megan and Sean are unusual and lovely. My favourite is the page about Imogen Cunningham, a photographer:

The second book Cynthia gave me is��Operation Marriage, a story about a family of four: two mothers and two children. The mothers are gay, and at the start of the book they haven’t yet married. When they first decided to commit their lives to each other, marriage of gay couples was not legal in their part of the world. The story tells how their two children get together to persuade them to marry.

Cynthia Chin-Lee is the author and Lea Lyon is the illustrator.

The story is sensitively and neatly told, and the illustrations are just gorgeous. This is my favourite page, showing the family settled down on the couch to watch a video of the mothers’ commitment ceremony:

You can find details of the books on Cynthia’s website.��Thank you Cynthia for a thoughtful gift.

API explorers – play with a REST API the easy way

To communicate with a REST API (or other web service API), you need to construct a request, send it over HTTP or HTTPS, then receive and parse the response. When creating an app, you do all that with code. But what if you just want to take a look around the API to see what it offers, before diving into the code? API explorers are your friend.

I’ve been putting together some information for a workshop��on API technical writing. It’s been a rewarding exercise, because it’s made me think in a structured, educational way about what I do every day. A section of the workshop deals with various online API explorers that��I’ve discovered over an extended period of time. This information is likely to be useful to many people, so I’m sharing��it��in a blog post.

API explorers offer a handy��GUI alternative to a command-line tool like cURL. This blog post introduces the��Advanced REST Client, which is a generic GUI for interacting with any REST API, and a few API explorers that interact with specific APIs.

Advanced REST Client

The Advanced REST Client is an add-on for Chrome browser. I find it very useful for sending a request to a REST��API and receiving the response.

The Advanced REST Client��offers a generic web form that you can use to��craft an HTTP request, submit the request, and see the response. The screenshot below shows the Advanced REST Client in a Chrome tab. The top text box contains a request for the Flickr REST API. You can see the URL path and the URL parameters specifying the options needed for this particular request: the method (get public photos), the user ID of the person whose photos you want, and an API key.

(Click the image to see a larger version.)

There are��more, similar add-ons for Chrome, such as the REST Console��and Postman. I haven’t looked at extensions��for other browsers, but I’m guessing there are similar tools for them too.

Explorers for specific APIs

Developers of REST APIs and other web service APIs sometimes offer an API explorer, which people can use to take a look around the API before diving into the code.

The principle is the same as��the��Advanced REST client: an API explorer provides an online form where you can enter the parameters required for an API request, submit the request, and see the results.

The difference is that an API explorer��is��written for a specific API, whereas the Advanced REST Client is generic.The explorer therefore knows more about the API that it���s accessing. It��can therefore:

Present specific input boxes for the expected URL parameters and the��input��data expected in the request body.
Hide such pesky complexities as user authentication. In many cases, you can sign in as a user of the web service, and the API explorer will create any authentication tokens that you need.

Flickr REST API Explorer

To see Flickr���s API explorer��in action, you can��experiment with��requesting a user���s public photos from Flickr. Follow these steps to use the��flickr.people.getPublicPhotos method in the API explorer:

Go to this link in your browser: https://www.flickr.com/services/api/explore/flickr.people.getPublicPhotos

You should see Flickr���s App Garden, showing a form with input fields for the arguments required in the request for public photos.
Enter the following values:

user_id: Paste in the Flickr user ID of the user whose public photos you wish to retrieve. A user ID is a string of characters with an @��sign in the middle. For example, use your own Flickr user ID or feel free to use mine: 31065906@N08.
Leave all the optional arguments empty.
Output: Select XML (REST). This is the default option.
Authentication: Select Do not sign call. (Flickr does not require authentication for this particular API request.)


Click Call Method.
Scroll down to see the response. The API explorer returns the response body, and a copy of the request URL.

This screenshot shows the input fields for the��flickr.people.getPublicPhotos��call:

To find all the methods available in Flickr���s API explorer, go to this web page: ��https://www.flickr.com/services/api/

The methods are listed down the right-hand side of the page. For example, to find the method you���ve used earlier:

Click the link on the words flickr.people.getPublicPhotos. You���ll see a documentation page about the getPublicPhotos method.
Scroll to the bottom, and click the link to the API Explorer for the method.

Twitter REST API Explorer

Twitter’s REST API requires user authentication for every request. The API explorer is especially useful in this case, because it takes care of the authentication plumbing for you. All you need to do is give the explorer permission to access Twitter’s data via your Twitter username. Twitter uses the OAuth 1.0 protocol to authenticate the user. In this case, you’re the user, because you’re using the API explorer. This will all become clear if you follow the steps below. :)

Go to the Twitter website and sign in as usual. (You do need a Twitter account to try this exercise.)
Go to the Twitter API explorer at��Exploring the Twitter API.
Click the dropdown arrow under��Authentication and select��OAuth 1.
A popup window appears, titled��Request Twitter permissions. If you can’t see it, scroll down the page a bit.
Click��Sign in with Twitter.
A window appears, titled Authorize Apigee’s API Console to use your account?
Click��Authorize app.
You should see a short-lived message saying that you’ll be redirected back to the app. Then you’ll find yourself back in the Twitter API explorer. Under��Authentication, you’ll see��Twitter- where is your Twitter handle. For example, for me it shows “Twitter-sarahmaddox”.
Under��Select an API method, you’ll see a list of methods – these are the things you can do with the API. Click��/statuses/user_timeline.json in the first set of methods (next to one of the��blue “GET” buttons).
A new set of panels appears. In the��Query��panel (the smallish panel near the top of the window), scroll down until you can see the��user_id and��screen_name fields. They’re right at the bottom of the panel, and not immediately visible. In the screenshot below, I’ve already scrolled down within the Query panel.
Enter a Twitter username and screen name. In this screenshot, I’ve entered my own Twitter ID:


Click��Send. (The red button near top right.)
A short-lived red-flashing message appears, letting you know the app is working. Then the response appears. If you see a green��200 OK, that means everything went well.
Scroll down to see the full response. It’s in JSON format. The top part of it looks like this (but there’s much more):



Various Google APIs

The Google APIs Explorer��provides a GUI interface for many of the Google APIs, including��the Calendar API, the Gmail API, and many more:

Happy exploring!

Educational programs and courses now in Tech Comm on a Map

Tech Comm on a Map now has a category for educational programs and courses, such as university technical communication degrees or certificates and other training courses. Take a look and let me know if you have something to add.

Tech Comm on a Map puts technical communication titbits onto an interactive map, together with the data and functionality provided by Google Maps. It���s a great way of seeing what we tech writers are up to, around the world. To find out more about the project, or to add something to the map, check out the project information page.

Webinar series on API tech writing, starting February 2015

The STC (Society for Technical Communication) is presenting a series of webinars (online seminars) on API technical writing, starting in February. I’m delighted to be presenting the first webinar in the series: Part 1: Introduction to API Technical Writing.

The role of API technical writer is exciting, rewarding, and challenging. In this webinar we’ll explore what an API is and does, see a couple of APIs in action (provided the demo gremlins stay away!), take a look at some examples of API documentation, and hear some tips on getting started in the role.

Details of the first webinar in the series

Date and time: Wednesday, 11 February 2015, at 2pm EST (GMT-5)����� that’s 6am here in Sydney!

Duration: One hour.

Fees and registration details: Please refer to the STC announcement:��Part 1 in API Series: Introduction to API Technical Writing.

Here’s an outline of the session:

Introduction to the role of API technical writer
Overview of the types of developer products we may be asked to document
What an API is and who uses it
A couple of live demos of APIs that you can play with at home
Types of APIs, including REST APIs, other web services, library-based APIs like JavaScript, and more
Examples of good API documentation
The components of API documentation, and the technical writer’s role in the creation of each component
Tips on getting started as an API technical writer

��Focus on APIs in the world of technical documentation

APIs are a hot topic in our field. Following on from my introductory webinar, the next two sessions in the STC’s series��have already been announced. In episode 2,��Ed Marshall talks about documentating Java and C++ APIs. In episode 3,��Joe Malin describes how to write effective code samples.

Then there’s my upcoming API workshop in January (now fully subscribed) sponsored by the STC and Google. Tom Johnson runs an API workshop at TC Camp 2015. The September edition��of Intercom focused on API technical writing. Tom Johnson has written some truly excellent blog posts on the subject over the last few months, the latest of which is��a podcast with Joe Malin.��Here’s a list of my own posts about APIs.

Are you into, or interested in, API tech writing?

Phew, a hot topic indeed. I’d love to know whether it’s something you’re interested in. Perhaps you’re dabbling in APIs, or already into them full time?

Workshop on API technical writing

I’m excited and delighted to announce that I’ll be presenting a one-day workshop on API technical writing, in conjunction with the Silicon Valley Chapter of the STC (Society for Technical Communication).��

The workshop��will be��a practical course on API technical writing, consisting of lectures interspersed with hands-on sessions where you’ll��apply what you’ve learned. The focus will be on APIs themselves as well as on documentation, since technical writers need to be able to understand and use a product before we��can document it.

Date: Friday, January 23rd, 2015

Time: 9 am to 4 pm

Location:��1295 Charleston Rd, Mountain View, CA 94043 (Google Maps: https://goo.gl/maps/yW1hu). The building is on the Google campus. The workshop takes place in the�����Araujo Tech Talk��� room on level 1.

Cost: None. The course is given free of charge, sponsored by Google and the STC Silicon Valley Chapter.

Notes:

STC membership is��not required.
The course is currently fully subscribed. But it’s worth adding your name to the waiting list, in case a place becomes available closer to the date. We’ll check the number of tickets and the waiting list early in January.
If you’ve registered but later��find you’re unable to attend, you can cancel your order in EventBrite. This will open up a��place��for people��who are on the waiting list.

Workshop description

The course will include the following sessions:

Lecture: Introduction to APIs, including a demo of some REST and JavaScript APIs.
Hands-on: Play with a REST API and a JavaScript API.
Lecture: JavaScript essentials.
Hands-on: Use JavaScript to exercise the sample JavaScript API in a more in-depth manner.
Lecture: The components of API documentation.
Hands-on: Generate reference documentation using Javadoc.
Lecture: Beyond Javadoc – other doc generation tools.

Details and signup

For details of food, what to bring, prerequisites, and how to sign up via EventBrite, please head on over to the STC Silicon Valley workshop page.

Questions and comments

Please let me know if you have any questions or comments.

Tech comm 2015 now on the map

Tech Comm on a Map now displays all the 2015 technical communication conferences that I’ve found so far. Take a look, and let me know if there are any more tech comm conferences, groups, businesses or societies to add.

Tech Comm on a Map puts technical communication titbits onto an interactive map, together with the data and functionality provided by Google Maps. It’s a great way of seeing what we tech writers are up to, around the world. To find out more about the project, or to add something to the map, check out the project information page.

Empathy in UX design and development

A new theme is emerging in the UX (user experience) world: Empathy. Putting humanity into technology. Product designers want to ensure they have empathy with the users of their product. We in the tech world want to design for what people need and want, rather than for what’s new and shiny. I think technical writers can contribute to this discussion!

Last month I attended Web Directions South 2014, a conference for people who “design, imagine, create or build digital products, web sites and applications”. A strong theme emerged at the conference: Empathy, what it means to be human in a digital world, creating an internet for humans… What’s more, this was a spontaneous emergence, not suggested by the conference organisers. It just happened.

My deduction was that this must be a “thing” in the world of web design and development at the moment, whether conscious or unconscious, whether generally known or just beginning to seep into our collective consciousness.

I’m wondering: how many other people have encountered this theme?

Since then, I’ve read a post by Georgina Laidlaw, entitled “Why Don’t You Have a Writer in Your UX Team?” (linked at the end of this post). Georgina was recently at the UX Australia Redux conference in Melbourne, where she noticed a “dearth of writers”. She follows that observation with an excellent and exciting description of the contributions a technical writer can make to a UX team: “five things a great writer knows better than anyone else in the room”. I’ll resist simply listing the five bullet points, because such a bald list wouldn’t do justice to Georgina’s post.

Georgina’s third point struck a chord: “Writers understand empathy“. She says,

Writers deal with emotion all the time. Even the writer of the blender manual is working to avoid frustrating or patronizing you, and to make things seem achievable so that you feel an affinity for the product you’ve bought.

Every professionally written item aims to communicate, and to do that, the writer needs to deal with emotion. They’re skilled at empathising with the target audience — the users of their words — whether that’s on a single-word basis, or a thousand-word basis.

I’d add these points: As technical writers, we focus on analysing our audience, thinking about how our customers work, what they want, and what they need. We get to see early version of the product we’re documenting, whether that be an app, an API, a piece of hardware, or another type of product. We exercise the product as a user would, in order to document its usage. Many of us interact with customers, via feedback on the docs, in forums, or in other ways. We see a different set of customers from those the product managers and marketing/sales teams focus on: we see and think about the “end users” (for want of a better term).

We can chat to the engineers, designers and product managers we work with, to share our insights. We can make ourselves known early in the design phase of a product, again to share our insights and also to expand our own knowledge of the product aims.

So, yes to Georgina and other UX specialists: let’s talk. :)

Here’s a link to Georgina Laidlaw’s post on SitePoint: Why Don’t You Have a Writer in Your UX Team? It’s well worth a read.

These links point to my notes on the four key-note presentations at Web Directions South: Interconnected, An Internet for Humans too, Being Human in a Digital World, A Voice for Everyone.

A pic from me, for fun:

Web Directions 2014 wrapup

This week I attended Web Directions South 2014, a conference for people who “design, imagine, create or build digital products, web sites and applications”. I’ve blogged about most of the sessions I attended. This post is a summary of my impressions, with links to the more detailed posts.

This was a technical conference for technical folk. Yet the presentations that went down best were those that mixed the human side in with the tech. Those that gave techniques for handling situations and people as well as code. Those that included humour and people in the slides. Code is for people by people.

A theme stood out in the keynote presentations and many of the other sessions: putting humanity into technology. There’s a concern that technical design focuses on what’s cool and new, when it should rather focus on what people need and how users want to interact with their tech.

The quality of the sessions overall was excellent. In particular, Sarah Mei’s presentation on day 1 gave me a lot to think about. Her idea is innovative and unusual: to analyse the way we make technical decisions, so that we can then apply the same process to the harder tech decisions. Jeremiah Lee’s talk on day 2, about what makes an excellent API, had some excellent nuggets of information that were particularly relevant to me as an API technical writer. I especially liked the bit about passive usability testing via analysis of existing data.

My own presentation was on day 1: Bit Rot in the Docs. It was a bit freaky – the sessions took place in a theatre, so I was literally on stage, with bright lights shining down on me and the audience in tiers of seats extending into the blackness.

Looking for more pics? Try Xavier Ho’s photos. There’s even one of me giving my presentation. (I’m in the fourth row of photos, third from the left.)

Here are my detailed notes:

Web Directions 2014 – day 1
Web Directions 2014 – day 2
Web Directions 2014 – Being human in a digital world
Bit rot in the documentation
Web Directions 2014 – Interconnected

A huge thanks to Maxine Sherrin and John Allsopp for the hard work and dedication they put into organising Web Directions. Thanks also to all the presenters and attendees. It was a great experience! Oh, and one final observation: The chocolate brownies were to die for.

Web Directions 2014 ��� day 2

This week I���m attending Web Directions South 2014, a conference for people who ���design, imagine, create or build digital products, web sites and applications���. I���m excited to be part of this event. I���ll blog about my take-aways from the sessions I attend, and anything else that comes to mind.

The keynote this morning was Being human in a digital world, by��Genevieve Bell. The link is to my post about that funny, inspiring talk. Now for my notes on the rest of the day.

Elements of API excellence, by��Jeremiah Lee

Jeremiah Lee is��lead API engineer at Fitbit. His talk was about evaluating the maturity of APIs, and what it takes to make an excellent API.

Jeremiah ran through some scenarios that may result in a bad API. For example, you may create an API unintentionally (it was just something we��auto-generated, and people started using it), selfishly (we looked only at our own requirements), or blindly (we imitated other APIs, without knowing why).

Instead, we��need to actively understand the problem that needs to be solved, and to test it thoroughly before letting it loose in the wild. And we��need to design it holistically. How? Tie up with our UX colleagues. We need to understand the people who use the code, as well as the code itself. The users of APIs are our peers – other engineers.

Empathy is an applied science. UX is a research-driven field. The aim is��to acquire knowledge, with the purpose of doing something with that knowledge.

An excellent API is functional, reliable, secure, usable and pleasurable. Jeremiah broke down each of those points into smaller divisions. For example, usability breaks down into intuitability, testability, and corrective guidance. Pleasurable means that integrating the API is something you’d choose to do again.

Personas are a useful way of getting to know your users. Remember, in this case the users are other developers. Personas describe the people who use the product and the context they operate in. Personas also make visible our assumptions about users, and give our team a frame of reference. Jeremiah took us through the development of personas for API users, and the type of characteristics we’d need to analyse to create such personas. For example, what technologies are they using, what’s their skill level, and more.

Passive usability testing is the idea that we can use our existing data and systems to test the usability of our APIs. For example, the engineers can examine the support requests with specific questions in mind: at what times are people asking for help – immediately after a release or on long-running software; what are the frequently asked questions; what are the frequently misunderstood concepts; and so on. Another passive usability testing technique is to look at the data about API usage during an integration: how long between app registration and first request; what are the first requests and first errors; and so on.

Then there’s active usability testing. Go out and talk to people who are using the API. Hang out with them at their place of work, and take notes about how they use the API. See how they talk about the API with the rest of their team; how do they get started and what problems do they encounter/solve; how does the API fit in with the rest of their app? Or create a prototype of the API, and have people use it. Jeremiah recommends Silverback to record the user’s reaction, and then look at their emotional responses at various points during the integration. Were they happy or sad, and can we fix the sad moments.

Jeremiah finished by saying he hasn’t given us answers to building an excellent API, because there are no one-fits-all answers. Instead, he has given us the tools to find those answers.

Build better content, by��Jonathon Colman

Jonathon Colman is a content strategist at Facebook. I’ve met Jonathon a couple of times, most recently at the STC Summit in Phoenix AZ earlier this year. It turns out we share the habit of waking up before the crack of dawn, and falling asleep soon after the birds stop tweeting for the day. We also share a love of technical writing. :)

Jonathan’s talk focused on how content strategy has to be part of UX strategy. He started off by promising us 127 slides! He’s a “madman with a clicker”. Heh. The slides are at bit.ly/fixourshit. Heh again.

First we looked at some definitions of content strategy. Then we saw some new Facebook content that aim to improve user experience, such as a privacy tool. It’s all about using language as an interface. Language is how we understand things. Content strategy is interaction design, because it focuses on experience, and the users of a product. Content strategy blurs the lines between engineering, design, testing, and so on. It crosses all those silos, focusing on the user. Jonathan calls this “intertwingling”.

The aim is��to design content as a system, a product and an experience. Not as a campaign. Jonathan aligns his strategy with Lean principles: build, measure, learn. He also stresses the importance of incorporating��your organisation’s core values into the design. And then go back and question your norms and values, especially if something breaks. Always remember that people are on the other end of the system.

“Slow down and fix your shit” – this is the essence of content strategy. Jonathan walked us through the quality framework his team uses at Facebook, and the content principles that guide them through the complex path of designing a product from strategy to the surface where the users see it. Aim for: simple, straightforward and human.

Thanks Jonathon for an information-packed session. Some quotes that made me think:

Keep it simple, get to the point, and talk like a person
Great content is invisible
If you want a better Web, you have to build it

A voice for everyone, by��Doug Bowman

Doug Bowman talked about his experiences as��Creative Director at Twitter, and how products like Twitter are giving people a voice. If eyes are the window to the soul, then the voice is the gateway to the heart. Whether the voice is spoken or written. A voice can change your day, or alter your life for ever. But a voice can only be powerful if it’s heard.

Doug��started working at Twitter five years ago, when there were no designers in the company. So he got to grow the designer team from scratch. He��loves Twitter. It’s connected him to so many people that he hadn’t met before.

The message that Doug wants to share is the human connection. Twitter is unique and wonderful because of the people who use it, not because of the service. We��can connect with anyone who shares an interest with us, whether we��know them or not. We get to overhear the conversations between people we don’t know.

Doug read out some tweets from conference attendees, showing lots of humour and character. He also��showed us some cute, funny tweets between people or businesses, famous and not. Where else do you see businesses taking the time to reply to random mentions of their name, and often��in the same humorous vein?��Then��we��looked at some more serious tweets among people mourning a loss or going through other difficult experiences.

Tweets are a series of human moments. But you can also analyse the tweets en masse, to see patterns. For example, the tweets mentioning #hungry spike at certain times of the day. How about the tag #tired – it’s the pulse of humanity. You can see when people tend to be happy, late for work, hung over…

Big events show a huge outpouring of emotion, such as when the Giants won the World Series, or shocking world events happen. Doug told us the story of Vivienne, who made a commitment to earn $100,000 to free 500 child slaves, by selling lemonade at a stand on her street for a year. That was 5 years ago, when she was 5 years old. Her father helped her tweet about it. She reached her goal in half the time planned. What’s more, she’s given a TED��Talk and runs a company that aims to end child slavery.

These stories of human connection were rooted in Twitter. But Doug’s��message is for everything we do. As communicators and designers, we are the creators of the modern age. It’s our responsibility to make sure everyone on this Earth has a voice.

Architecting the rise of connected devices, by��Hadi Michael

Hadi Michael is��a digital adviser and software engineer at��Deloitte Digital. He gave the first of three 15-minute sessions. His talk is about the importance of API layers in the growth of the Internet of Things. An example of a connected device might be a chair. It could have sensors, activators, computational power, and connectivity. The powerful idea is that the devices have contextual awareness. Some devices may decide to activate when you leave the home, such as those that clean the house. Others may switch off when you leave. Cisco estimates that we’ll have 50 billion connected devices by 2020. And that’s a conservative estimate.

How are we going to handle this – how will our solution architectures service this growing number of connected devices? Hadi showed us how various organisations have started preparing. Those that are successful have API layers at the core of their architectures, either unifying their API layer retrospectively, or doing it right from the start. The trick is to move your business systems behind the API layer, at least when there’s any chance that you’ll want to expose those systems to anything other than just the website.

Hadi walked through some tips for designers when taking connected devices into account.��Thanks for a tantalising glimpse into the world of connected design!

Welcome to the fold, by Katie Miller

Katie Miller is��an OpenShift Developer Advocate at Red Hat. Her presentation, the second 15-minute session, was about higher order functions in JavaScript. Katie��started with a story about a secret garden, a chain of paper dolls, and a bowl of pebbles. That was a surprise! The rest of Katie’s��talk was about fold, also known as reduce, and how to use��it to write elegant JavaScript code. A higher-order function (HOF) is any function that takes another function as a parameter. Famous examples of HOFs are the map and filter functions, which can also be written as a fold.

Be aware also that there is a family of fold functions, such as fold left and fold right. Katie’s slides, with references, are at fold.codemiller.com.

Responsive in the wild, by��Guy Podjarny

Guy Podjarny is Chief Technology Officer at��Akamai. Guy’s talk was��about the adoption of responsive web design. Which websites are going response, and how are we architecting them?

When we try to see if a website is responsive, we usually just resize the page and see if the content is cut off. We also look for a scrollbar, which indicates a non-responsive site. This isn’t ideal, but it’s pretty good and we can automate it. Guy showed us the details of the test he ran, and the results. Here are some highlights.

The adoption in the top 10,000 sites has grown by approx 8% over the last year.��The average number of requests in responsive websites is substantially lower than non-responsive.��The average resource size in the responsive websites is��bigger. Interestingly, the image size is also bigger in responsive sites – perhaps because of retina?

Guy also compared responsive designs on the big screen with the small screen. We’d expect a substantially lower volume of data on the small screen. That’s not the pattern that shows up, presumably because the resources are downloaded anyway and then just hidden or shrunk on the client. Only approx 13% of responsive websites are 50%+ smaller on mobile. We’re doing better here than last year, but still need to make an effort.

Mobile-only sites are significantly smaller than responsive sites. Processing time follows the same pattern. Responsive sites take longer to process than mobile sites.

In summary: Adoption of responsive design��has nearly doubled in less than a year. But we need to work on the performance.

Haunted machines, by Tobias Revell

Tobias Revell is��a critical designer and futurist. He gave the closing keynote of the conference. Note: Today is 31 October. Halloween!

Tobias’s talk revolved around the notion that any sufficiently advanced technology is indistinguishable from magic. (From Arthur C Clarke.) Tobias gave some examples of recent hoaxes: that if you add this app to your phone, it will become waterproof, or that you can��put your phone in a microwave oven to recharge it. The amazing thing is that people fell for these hoaxes. But the fact��is that people are dealing with such advanced technology that they can’t understand it. As technology gets more and more advanced, it gets more and more opaque.

On the other hand, people have built computers on Minecraft. Some people are even trying to build a computer on Minecraft that you can play Minecraft on. Go figure.

Tobias gave us a link to his site: The Ongoing Collapse,��“a growing collection of data sources and links positioned as a reflection of the state of the world in the terms that it likes to use. It’s a gentle ticking of the crumbling weird at the base of civilisation”. (More about the site.)

Tobias ended with this somewhat convoluted, dark thought: As makers of virtual reality, we control people’s��perception of objective reality. Happy Halloween!

Thanks Tobias for a rollercoaster ride past ghosts and technologies past, present and future.