- Are you struggling with producing readable web sites?
- Do you need to make a site or sites that walks like a book, talks like a book, and reads like a book but everything you make looks like a blog?
- Are you having trouble dealing with file formats such as PDF, DOCX, or EPUB using web tech?
- Are you trying to produce PDFs or ebooks from your website or your CMS?
- Do your customers need to be able to annotate text or images in your app but nothing in your code is set up for it?
- Do you need to do any of the above in an accessible way?
- Do you need somebody to write about these issues in a clear way?
I have twenty years of experience working on and researching interactive media and the web, most of it focused on problems facing publishers and readers. I was making websites in the late 90s, even before I went to college. In 2006 I got a PhD in ebook interactivity from the University of the West of England and since then I have worked for publishers, big and small, ecommerce sites (turns out writing sells and readable writing sells better), software companies, and education/publishing startups. I’ve held a number of talks on web standards, ebooks and web tech in publishing in conferences all around the world.
I’ve been writing on this website on web development and interactive media for over a decade and on other web sites for a decade before that.
I’ve worked with React (with hooks) and other frameworks in the past and can re-familiarise myself with them relatively quickly. Although I generally don’t recommend using these frameworks for new projects (they are rarely a good fit) I’m also firmly of the belief that working code trumps other concerns. Rewriting a working codebase in a new and unfamiliar framework is a recipe for disaster.
(If you’re starting something new, however, then that’s exactly the time to pick the technology that works best for your problem domain and business model and that’s exactly a problem I can help you with.)
I’m available for consultation projects, coding projects, and (if the offer is interesting enough) for hire. I work remotely from Iceland which makes European timezones the most convenient. But I am flexible enough in my workday to accommodate east coast North American timezones.
For consultation, I have a few standard suggestions but, I’m of course open to all kinds of projects and processes:
- The feedback. I meet with you, hear what your problems are, read your documentation and, after processing it, hold a meeting with you where I give my feedback on the problem and make suggestions for how to solve your problems in the most cost-effective way. About a day’s work and priced as a day.
- The paper. I meet with you and your team. I then look through your material and write up a six page paper outlining the problems and my suggestions. A week.
- The workshop and a paper. As above but followed by a day-long (or two half days) workshop with your team coaching them in the issues. Two weeks.
- The code review retainer. For a moderate monthly fee I get tagged in to review all pull requests that pertain to my expertise, making suggestions for improvements if needed.
The code review retainer is an experiment I’m trying out. What it would mean is that if something comes up and you need someone to jump in to help code to solve a problem or get something done, then you can pay me to jump in. One of the biggest problems in software development is that adding developers always slows work down first before it makes it faster because it takes time for anybody to become familiar enough with the code to be productive.
By having a consultant on a code review retainer, you have an experienced developer at hand who is already familiar with your codebase and can jump right in to work. Which means you can add a developer to your team exactly when you need to.