Apple has released a new version of iOS, which includes the Health app. Health is meant to be a central place where you can get an overview of your health and fitness, with data provided either by third-party apps, the Health app itself, or manually by the user.
The release of HealthKit (the developer framework for integrating other apps with Health) is delayed due to bugs, but the Health app is already available.
Before the new operating system was released, I was really interested in the Health app already, but something was missing from the promotional materials: tracking menstrual cycles. I thought perhaps that the materials presented “Jonh Appleseed” as the app’s user, and perhaps John doesn’t menstruate.
When I checked the documentation for HealthKit to see how cycle tracking data can be integrated into the Health app from third-party sources, I was disappointed to find out that Apple did not include anything related to menstruation and the reproductive health of roughly half of the world’s population.
In case you’re wondering whether Health is only concerned with a few basics: Apple has predicted the need to input data about blood oxygen saturation, your daily molybdenum or pathogenic acid intake, cycling distance, number of times fallen and your electrodermal activity, but nothing to do with recording information about your menstrual cycle.
I wanted to know more about whether people keep track of their cycles in any way, and why they do it, so I made a short survey about it. Eighty four people responded, of whom 89% have experienced menstruation, so the sample is small. The answers were interesting nonetheless.
Of my small sample 43% currently track their cycles, but two in three responded that they have done so in the past.
Of those who do not track, some respondents can predict when their next menstruation is likely to begin, either due to their contraception method dictating when it will occur (34%), or one in five through other means (potentially being able to read changes in the body signifying cycle stages, but I didn’t ask for details). Multiple answers were allowed, so there may be overlap between those groups.
Menstruation, changes in menstruation, or lack of menstruation can be signs of other health problems. One of the respondents to my survey only menstruates when they are ill due to treatment they had in the past, for example.
Things that could be signs of abnormalities:
However, those characteristics can be perfectly normal for some individuals, and this knowledge sometimes comes by tracking past data and seeing patterns on a larger scale. Especially in cases where one’s individual cycle characteristics are uncommon it can be harder to detect changes without tracking different aspects.
Migraines, for example, can be triggered by periods (or more accurately, falling oestrogen levels just before menstruation), so it’s useful to be able to predict when it’s likely that your ability to work will be affected.
For the majority of those who answered my survey, the reasons for tracking were mainly detecting irregularities (68% of people picked this answer), knowing when to purchase sanitary items (81%), and learning about one’s cycle (52%).
Many respondents mentioned the effects of their cycle on other areas of life.
I can predict my cycle in my head, but I want info relevant to the momentary state of my health, like a body-weather report, e.g. “likely to be achey today; try for extra water and sleep”
Commonly mentioned is the ability to plan work and leisure activities away from days which are likely to be very painful.
ALL the period tracking apps are trying to get me pregnant. I just want to know if I need to pack my cup on a weekend trip and when the first day of my last period was so I can book paps
Checking that contraceptive methods work was also mentioned as one of the reasons for recording cycles, whether the respondent used barrier protection, UID or hormonal methods.
In many cases, health professionals will ask you about the date of your last period. There are many reasons for this. One is to detect variations from the norm as previously mentioned. Knowing the cycle pattern might be useful to detect various health problems and any unwanted effects of medication. It’s common to arrange or adapt body examinations depending on the stage of the menstrual cycle (e.g. colposcopy, cervical smear, breast and pelvic examinations, urine tests).
Emergency health workers will ask about your last period so they know whether they should act as if there’s a possibility of pregnancy, in which case some treatments can be withheld or substituted. This is the kind of information that should have found its way onto Apple’s Medical ID so it could be made available to emergency services.
The average age of the first period is thirteen years, and last one on average happens when the person is fifty-one years old.
I wanted to know how many people are of menstruating age at any given time. Worldwide data from the US government census for 2013 is banded by age groups, so to be err on the side of caution I’ve selected ranges between 15 and 49 as the menstruating ages. Of course not all of those people will actually menstruate, but I hope that the difference is insignificant.
By this estimate, over 1.8 billion people are currently of menstruating age. That’s just over a quarter of the population. If you also include people who have menstruated or are yet to menstruate then of course that number is approaching half the world’s population. That’s a huge potential audience, of whom a large proportion might be interested in recording their cycles at some point in their lives.
Tracking cycles isn’t anything new, it has been done since the dawn of time, in many different forms. I am pretty sure it was the first ever occurrence of Quantified Self movement, although for reasons I cannot understand cycle tracking doesn’t feature very prominently in it.
Apple did take the lead on something they thought was important even though it didn’t affect a high percentage of the user base: accessibility. It was so important that making apps made with built-in components are accessible by default, without the developer needing to know anything about accessibility. Apple took care of it, because it was the right thing to do, not because it was the killer feature that everyone demanded.
In the same way, the iPhone includes the Stocks app by default, because Apple decided that checking stocks is a very important thing to do. So important in fact, that no user should be able to delete Stocks from their phone. I haven’t found any data on the total percentage of the population that owns stocks, but I can’t imagine it’s bigger than the percentage of people with disabilities or a menstrual cycle.
Perhaps it’s because some people are opposed to knowing about the bodies of nearly half the population in such detail, and opposed to giving people tools to help them be in control of their own bodies. This could affect sales among certain kinds of people. That is however inconsistent with Apple’s stance on issues they care about. Despite the fact that support for LGBT rights is not universal, Apple openly supported marriage equality. Tim Cook gave an impassioned speech about human rights and immigration reform, and said that some things have to be done “because they are right and just”.
Perhaps it’s because Health is intended to collect data from sensors rather than manually input information? Apple explicitly states that manually entered data is to be collected too:
HealthKit makes it easy for apps to share health-related information, whether that information comes from devices connected to an iOS device or is entered manually by the user. (source)
In addition, there are already many apps designed for tracking periods, although many of my survey respondents mentioned that they’re too gendered (there were many complaints about colour schemes, needless ornamentation and twee language), difficult to use, too focused on conceiving, or not taking into account things that the respondents wanted to track.
So why isn’t cycle tracking present in the Health app? I don’t know, but the only valid reason I can think of is that it didn’t occur to anyone to include it.
There has been a lot of discussion about corporate hack days, prompted by the Unilever hack day called Re.Hack with the tagline “reinventing Commerce”.
I know people working for design agencies who do spec (speculative) work. It’s risky and disheartening, but impossible to avoid for some companies. One person I spoke to a long time ago used to spend two thirds of their time doing spec work, and win only a third of the contracts. Not a desirable position to be in if you have several employees.
For a freelancer, attending a two day event is not as damaging as putting a whole agency on a project for a week, but that time still costs money in missed opportunities.
I’ve heard of day rates in tech from as low as £200 per day to well over £1500. Two days not working for other clients works out at anything between £400 and £3000+. That’s not including any time spent working in the evening or even through the night.
3beards, the organisers of Re.Hack pointed out in their blog post that intellectual property rights remain with the participants, they all have chances to win prizes, and potentially a commercial contract with Unilever. I don’t think this is enough: simply retaining ownership of what you produce is not adequate payment for consultancy services. Nor is a chance to win a Fitbit.
I don’t mean to pick on this one event, it’s far from the worst I’ve seen, but it’s a good recent example of a multinational corporation either being misguided or downright cynical in their approach to generating new ideas for as little as possible.
The Cadbury Olympic hack day springs to mind. It generated so much vocal criticism that the rules of the event were changed to highlight the benefits of participation, mainly through stipulating what prizes could be won and that participants would retain the IP.
And can you remember the one where you had to pay cash money (i.e. buy a ticket) to do some free work for McDonald’s (event is now password protected)?
Big companies often cite the freshness of the ideas coming from hack days as the primary reason for hosting one, and organising that kind of event is a perfectly valid way to explore some challenges. However, there’s no reason for these events to be exploitative to achieve their aims.
One approach is to organise internal hack days, where people who already have domain knowledge, or people from other departments, can use their strengths to bring about new ways of thinking. They don’t have to work for free, you keep all the IP, and your costs are low. There are additional benefits: tightening up of existing internal networks, creation of new ones, generation of new interests and enthusiasm, and the opportunity to try out and learn new things. All those benefits are retained within the organisation. It’s such a successful model that even the government organises events like that.
Another one is simply paying people for their time. The BBC runs an event called Connected Studio (which I have participated in) where groups are given a subject area. Then they have some time to develop and pitch ideas. Interesting ones may be further developed in conjunction with the BBC and potentially commissioned. All participants are paid a fixed day rate for their work.
I have been to hack days of both kinds, and some that mixed the two approaches: bringing in professionals to an internal hack day can bring some new ideas and approaches and encourage collaboration. I have a very positive view of what was accomplished during the events that I have attended.
But organising a hack day is not the only way to get similar results. You can for example make multiple small commissions. When the Royal Shakespeare Theatre wanted to see lots of small projects developed for the World Shakespeare Festival they made a number of tiny commissions from technologists, artists and students. Instead of hosting a single event, the projects were developed over a longer time and provided many interesting ways to think about Shakespeare’s work and influence. A similar approach is something Thayer Prime suggests in her blog post too:
As well as paid hack days, companies/brands could consider another professional alternative: do prototyping days with developers who can create apps and products for you in quick time frames at relatively low cost compared to fully developed projects, so you can fail fast on stuff you don’t like and move forward with the innovations you like.
Because there are so many ways to both spend little money and source a variety of ideas, it is really disappointing when companies think they can get away with soliciting work for a promise of a chance to win something, exposure, and so on. For someone like Unilever, who made 5.3bn€ profit just last year, it smacks of cynical opportunism. They clearly value the work so little that they are unwilling to commit to paying a fair price for it. Either that or it has become normal to assume that developers have so much spare time and expertise that they will produce original ideas (or, as the Unilever event page puts it, ”Ideas need to be 100% original and not based on existing products”) for some beers and pizza. I doubt the event hosts, organisers and judges are working for the same remuneration.
Many people in the industry are passionate about things they care about to the extent that they will give up their weekends to tackle some challenges, or think about problems and possible solutions, and I’m not criticising that. NHS Hackdays regularly bring together people who want to help solve real problems faced by the health system. There are others that often attracti large numbers of participants, dealing with questions of privacy, civic involvement, communication of complex issues, collaboratively learning something, making music, and so on. Participants are unpaid, but they get some clear value out of those events. Meeting new people, learning new things, thinking about challenges that interest them. These are all great motivations, as long as they are not exploited by for-profit companies to generate more value for their shareholders, at the cost of participants’ expertise and spare time.
I don’t often have the opportunity to play with the latest browser technologies in client projects, unless they’re quick prototypes. When Artangel approached me about a project bringing Paul Pfeiffer’s work to the Space I realised that it would be best done using the Web Audio API. At the time, the Web Audio API was so new that the day I began building the prototype Mozilla shipped a way of inspecting the audio nodes in Firefox Aurora for the first time.
Paul Pfeiffer’s work is based around footage from the 1966 World Cup match between England and Germany from which most of the players were algorithmically removed — done in cooperation with machine vision expert, Brian Fulkerson. Jerusalem isn’t the first piece in which Paul Pfeiffer erases elements from iconic imagery, but it’s the first to be presented exclusively online.
Jerusalem blends the archival, reworked footage with audio and video clips that bring in context from 1966 and link it to other themes present in Paul’s work.
When I began working on the first prototype there were a few ideas about when the audio tracks should become available to play. I decided to implement simple rulesets which could be combined together to express complex relationships between each track and the main video. For example, some tracks might appear only on the second play through, but only to 40% of viewers, as long as the viewer has already heard at least two of the other tracks. This was intended to give the work a bit of unpredictability and make it seem a little different every time it’s viewed.
Rules were expressed as data attributes on each additional audio and video track, meaning that combining or changing them was trivial to do. It also meant that adding new types of rules was straightforward.
As the work began taking shape most of my initial assumptions about rules were abandoned, as we realised that the experience seemed too confusing. Instead, we decided to present the viewer with an interface to play each additional audio track after thirty seconds. To help understand what the interface represents, some of the audio tracks play for a set duration at certain times, highlighting the UI elements - little previews if you like. Again, that information is communicated through rules in the markup. Here’s an example:
<audio id="bees" preload="auto" data-offset="30" data-preview-length="19" data-on-loops="1"> <!-- sources --> </audio>
This track plays 30 seconds into the main track, lasts 19 seconds and only appears on the first play of the main track.
There are also video interruptions, over which the viewer has no control. These are timed using information specified in the markup.
Specifying rules this way turned out to be very flexible and accommodated many changes that were made since the initial prototype. Despite throwing out a bunch of sample rules I dreamed up at the beginning, the structure for defining and applying them made it easy to expand and develop the work.
Very light browser feature detection is being done, mainly to check for the presence of HTML5 audio and video support. If it’s not possible to play media natively then the work cannot be viewed. If it is, then depending on the Web Audio API availability the viewer either has a basic or slightly richer experience.
In the basic version the audio tracks are crossfaded using just the volume property on the audio elements. When the Web Audio API is available, then a subtle low pass filter is added during the crossfade and to the main track, which is always audible in the background, making it seem a little muffled.
AudioParam, part of Web Audio API, allows you to do a bunch of really cool things: you can ramp the value of an effect to a specific value at a specific time in multiple ways (linear or exponential) for example, which allows fine-grained control over sound. Though Jerusalem is relatively simple when it comes to audio manipulation, I can see how powerful the new features would be in the hands of someone who really knew what they were doing.
I don’t know very much about audio, so it’s hard for me to imagine just what is possible with the new browser capabilities, but Chris Lowis showcases interesting projects and new Web Audio API features in his weekly newsletter.
Stories of startups are most often told using superlatives. These are stories of founders dedicating themselves to a single idea, prepared to risk it all for a chance of success. Teams putting in extraordinary effort: their sweat, late nights, and swapping socialising outside of work for obsessively improving their products.
These are always heroic tales of turning talent and youth into success and money. They are so pervasive that in some circles it is automatically assumed that your goal is to either have your own startup eventually, or be a part of one destined to make you rich.
Even outside of the tech bubble many believe the hype. The government is happy to claim to have played a part in the success of Silicon Roundabout, whatever that success may be. Young people skilled at programming are hailed “the next Zuckerberg”, their companies “the next Google”.
The sad truth is that most startups fail, but these stories are always presented as post-mortems: we did this, and it hurt us in that way. We ran out of money. We couldn’t scale.
As Nikki Durkin points out, “the startup press glorify hardship”. As a founder, you’re expected to put on a brave face.
Ask any founder how they’re doing and you’ll hear something positive. Whether that’s the truth or not, that’s what we’re trained to say.
I found postmortems of startups outlining what didn’t work and why the company went under, but I was hard pressed to find anything that talked about the emotional side of failure — how it actually feels to invest many years of your life and your blood, sweat and tears, only for your startup to fall head first off a cliff.
Of the personal stories of my friends most of them are not the happy ones of hardship, survival and success. Mostly they’re stories of workplaces that in the name of innovation and moving fast throw out healthy working practices. I’ve heard of startups doing “agile” by having three stand ups a day. Ones which insisted they were still too small for HR departments despite complaints. Companies where managers were so scared of losing control that they had to micromanage everyone below them. Places which enforced permanent “crunch time”. Stories of unfair dismissals, unforeseen firings, burn out resulting in months off work.
Anecdotally at least it seems to me that those stories are at least as common as the success ones, but they’re not told as often, though they should be. That’s why I made the Startup Game (mirror here).
Last year I felt an itch to start saving my digital records from obliteration next time a service I use gets shut down or sold. For ages I’ve been thinking of dipping the toe in the world of hosting all my own data. paralell-flickr by Aaron Straup Cope sounded like a good project to try.
paralell-flickr is a really thoughtful piece of software. You still put your photos on Flickr, and keep up with your friends there (or rather, you used to, when your friends were still using it), but on your own server you keep a replica, a copy that keeps track of your contacts, favourites, and permissions. You have to sign into it using your Flickr account and it will know who can see which photos.
As the readme states:
parallel-flickr is not a replacement for Flickr. It is an effort to investigate – in working code – what it means to create an archive of a service as a living, breathing “shadow” copy rather than a snapshot frozen in time.
I thought that having my own parallel copy of each service I use — Foursquare, Instagram, Flickr, Twitter — would be a good way to preserve my data without hassle, and if I ever decide to delete my account, or for another reason won’t be able to carry on using it, at least I’d already have a complete backup in place.
The moment when parallel-flickr came in handy happened sooner than I anticipated.
I created my main account in 2010, but have another two which date back to 2008 and 2006. Flickr lets you personalise your URL, so that’s what I did, every time, and I’ve grown to regret it. The URL on my main account has a name in it that I don’t go by anymore. It annoys me because it denotes gender that doesn’t match mine, so I want to change it.
But Flickr wasn’t built with that kind of flexibility in mind. You can change your username, and all the other details, but not the URLs. Once you choose one, that’s it, game over. Permanence of the URLs is more important than your comfort, your life, your future choices and changes you cannot anticipate.
There are a million reasons why you’d want to change the URL other people find you by. Perhaps it was funny 7 years ago when you called yourself grandma_disco_fever but now you no longer do. Maybe mother_of_three was a good moniker a while back, but now you need to increment that number. What if you called yourself wife-of-someone but you’ve since divorced? Maybe these things don’t immediately spring to mind in the first year of the service’s existence, but once you’ve spent many years building an archive, full of connections and relationships, it becomes hard to leave it behind just so you don’t have to be a prisoner of your past URL choice.
We don’t arrive in the world as fully formed, unchangeable entities. We’re not finished and permanent, and when dealing with URLs of people it seems deliberately harsh to demand permanence. Especially when the HTTP spec accommodates redirection to new ones.
So, Flickr, I think this is goodbye.