Accessibility, Design and Technology Meeting – 3 December 2011

The Accessibility, Design and Technology committee oversees technology-related projects within the OTW. Currently we are responsible for designing and building the Archive of Our Own. Our regular meeting updates keep you informed about developments on the AO3!

This was our final meeting of the year: the OTW takes an end-of-year break during which committees dissolve and are reformed, and committee members take a well-earned rest! We’ve had an action-packed year, so we’re all ready for a break (from meetings at least – a lot of our work goes on as usual). We’ll resume in January – we don’t take on any new volunteers during our hiatus, so if you volunteer between now and then (and we hope you will – as you can see below, there are several areas we’re really keen to build up), you’ll have to wait a little while to get started.

Meeting highlights!

Fandom landing pad!

AD&T co-chair and senior coder Elz has been working for a while on improvements to browsing on the Archive. One thing she’s been working on is a new ‘fandom landing pad’ so that browsing to a fandom will give you the option to browse to some important areas relating to that fandom. In this meeting we previewed her new design – going to a fandom landing page will give you a list of pairings and relationships in the fandom, and a list of authors and artists who have created work in that fandom, along with some basic information about the canon source. It’s not quite ready for primetime yet, but it’s looking very nifty!

Issues for Love!

Issues for love are the requests submitted by users via Support. We try to work through a few of these each meeting: we’re working on ways of making it easier for people to see what has been suggested and what has been decided about the suggestions, but for now we’ll include a round-up of our discussions in our meeting updates. Note that a decision to implement something does not necessarily mean it will be implemented soon – we have many issues to work on and a limited number of coders! If you want to see the full (and lengthy!) list of things logged for coders to work on you can check out our Google Code Issues. If you’d like to adopt an issue, we welcome new coders!

  • Request to add a setting to prompt-meme challenges to disallow anonymous prompts. This seemed like a handy extra feature without too much coding complexity, so we have logged it as an issue for a coder to work on.
  • Request to add an option to hide ‘Share’ buttons on works to reclaim screen real estate. It’s already possible to disallow use of the share button on your own works, but you still see the button. We sympathise with the desire to reclaim the screen real estate, but we decided that added a user preference to hide the buttons would add too much complexity (the more user preferences there are, the more complicated it becomes for people to figure out what they can set in preferences, so we try to limit the options to things where there is a lot of demand for a setting). Instead, we added some extra code to our buttons so that they can be selected with CSS, so that people can build skins which hide the ‘Share’ button (or indeed any other button).
  • Suggestion for a ‘challenge calendar’ listing opening and closing dates for challenge sign-ups, and dates for assignments due, works revealed, authors revealed, etc, which can be opted in when a mod creates the challenge. We loved this idea, but it is fairly complex to implement. Our lovely co-chair Amelia has volunteered to put together a design, so this is something we’ll introduce in the future – but probably not for a while.
  • Request for a way to mark WIPs as abandoned, and a way to offer abandoned WIPs up for ‘adoption’ so that someone can finish them. We all agreed it would be really nice to have a quick way to flag that a WIP would never be finished, so we’ve logged that as an issue for a coder to implement. The idea of offering works up for adoption seems like it might have more limited appeal, so we agreed that for now, it would be better to leave this as something which people can simply indicate in the tags they use, if so desired (you can add ‘Adopt this story’ or indeed any other tag you wish as an additional tag to your work).

Reflecting on Release 0.8.9

As most of you reading this will know, we had a big release of new code at the beginning of November. This release included a lot of exciting new stuff; unfortunately, it didn’t go as smoothly as we had hoped. In this meeting we reflected on problematic areas and ways that we can improve in future:

  • We combined two big new features: the redesign of our front-end code and the new tag sets code for challenges and collections. We had decided to combine the two because the tag sets needed some front-end work anyway, and at the time we made the decision it made sense to roll the two things into one. However, the tag sets code was time sensitive: because it offers a new system of challenge nominations which significantly reduces the pressure on tag wranglers, we wanted to implement it in time for the big holiday challenges such as Yuletide. This meant that when we combined the two features, we had a lot more stuff to get ready within a set amount of time, which made everything more difficult. When we decided to merge the two, it didn’t seem as if this was going to be a problem – but one thing we’ve learnt is that any deploy can bring unexpected hitches, so in the future if there’s a time-sensitive feature we’ll be trying to keep that as separate from other code as possible.
  • This was a big visual change, which meant that it had an impact on a large number of users: visual bugs tend to be encountered by lots of users, and even if there are no bugs, people still have lots of feedback about visual changes. We were aware of this; however, given the scale of the response to this deploy we realise we weren’t prepared enough. We’ll be doing more testing of interface changes in future, and exploring ways of beta-testing them with more users.
  • Since one thing about visual changes is that lots of people just prefer the design they are used to, one thing we could have improved on was providing a way of going back to the old default design. We tried to provide for this with the One Point Faux option, but it had quite a few problems. So, in future this is something we’ll be paying more attention to: if we introduce a big change, we’ll try to provide ways of opting out. The good news is that going forward, this will actually be easier, because the new skins system is much more lightweight and it should be easier to provide some backwards compatibility (one reason this was problematic this time is because the underlying code for the old system was less than ideal, so everything had been completely rewritten).
  • We didn’t have as much support documentation and information as we really needed for this deploy. In particular, we needed much fuller documentation on the new skins features so that people could try them out more easily and our Support team could point to useful information when helping people. There were several factors which led to a lack of documentation: crucially, several of the team who would normally take care of this were dealing with RL issues which limited the amount of time they could spend on it. In order to help avoid problems like this in future, we’re building a deploy checklist which includes documentation, to make sure that we’ve considered whether we need additional documentation regardless of who is available to work on any given deploy. We’re also aiming to build up a proper documentation team so that this work is less likely to fall through the cracks: if you’re interested in being involved in this team, get in touch with our Volunteers and Recruitment Committee and let them know. We’d love to welcome new people to the team!
  • We also needed more documentation on the new features for testers, so that it was clearer what people needed to test and what they should expect it to do. This is an ongoing aim – we’re working to improve our documentation across the board. Improving documentation for testers will also help us to address another issue, which was that feedback from testers got a bit scattered – having clear docs to start with would have helped us make it clearer what feedback needed to go where. Again, we’re working on building up our testing procedures generally – if you’re interested in getting involved with testing, let us know!

While the problems we had with this deploy did highlight a number of areas where we need to work to improve, it’s not all doom and gloom! There were also a number of things that went right with this deploy – we were able to fix critical bugs within 48 hours of the deploy, the Support team did a wonderful job keeping up with the many Support requests, and there was a huge amount of awesome code in the deploy itself. One reason the site is still in beta is that we’re still learning the best processes for development (as well as because our code is new and rapidly changing): in the last four years we’ve gone from being a tiny group working on coding a ‘closed’ site (i.e. for the first two years we were just writing the code and testing, we didn’t have any real users) to being a much larger group catering for a site of over 28800 users! So, we’re still figuring things out – objects may still shift in transit! We’re pleased that we’ve been able to keep the site up and running, and everything largely functional, even though we’ve had the odd bump along the way. Thanks to everyone who has worked hard to make this true!

Next deploy

We’re hoping to get one last deploy in before the end of 2011! It will include some updates to our HTML parser, some improvements to our static pages for collections and challenges, and Atom feeds for fandom tags! (YEAY!)

News from our sub-committees

  • Coders have been working on polishing off the issues to go in the next deploy. We’re particularly excited about the forthcoming addition of Atom feeds for fandom tags – having tested this out for a good while now on the F/F tag, we think we can implement feeds without too much additional strain on the servers, and since this is a very popular request we’re excited about launching it!
  • Testers have been testing the issues for next deploy, and discussing how they’d like to see the subcommittee develop next year. There have been some great discussions on what worked and what didn’t this year, how we can build a stronger testing community, and how we can support our testers.

News from our sister committees

  • Support have continued to work amazingly hard keeping up with a high number of tickets. Looking forward, they’re also thinking about our documentation needs and places we need more information for users.
  • Tag wranglers have been discussing needs for next year with AD&T – the two committees will be meeting in the new term to talk over technical needs for tag wrangling. They’ve also been surveying all tag wrangling volunteers about their experiences this year, with a view to figuring out what works well and what can be improved on.

If there are things you’d like to do or say, please share them in comments, via the AO3 support and feedback form, by volunteering (we won’t be taking on new volunteers until the new term, but you can get in touch now to let us know you’re interested), or in whatever medium you feel comfortable with. Everyone is welcome to this party!

This meeting round-up by Lucy

Mirrored from an original post on the Archive of Our Own.

Archive of Our Own

Comments are closed.