Bookey 2.0 — new release

Amir Jabari
9 min readJan 4, 2021

Over the last few months, the Bookey team has been working on a new release. This has taken longer than expected but we’ve finally got here and we’re excited to share it with you. This release will bring all the functionality to the website as a Progressive Web Application.

First, let’s talk about what’s changed!

One of the key pieces of feedback we got on the first release was that the UI needed to be better. With the help of Ray Wong, we managed to improve the design and make it easier to use. We hope you like it!

You can now view someone’s profile by clicking on their picture. This lets you see all of their books, see the books they’ve liked, as well as recommend them a book that you think they might like!

We heard that some people’s devices were having problems with scanning some books’ barcodes, so we’ve created a new way to add books. You can now search the title of a book and choose from millions of books from our database.

Now, I’m going to detail some of the trials and tribulations of this process and hopefully pass on some knowledge that I think would be useful to other development teams.

Agenda

  1. Finding time to work on your project
  2. Spreading the word on a shoestring budget
  3. Progressive Web Applications vs mobile apps
  4. Accessibility and device-agnostic websites
  5. On-boarding a junior developer
  6. Testing

1. Finding time to work on your project

The release of this version has taken longer than expected and it has been tricky to find motivation in such a difficult year. A lot of you may not be aware of this, but I was working full-time alongside juggling my commitments with Bookey. I spent many evenings trying to muster the energy to code after having spent the whole day coding at my day job. It was difficult and frustrating as coding is an intensive task that you need to be fresh for. One of the hacks I discovered was waking up a bit earlier on weekends. This allowed me to get a few hours of productive work in and still allowed me to enjoy my weekend as I would finish up when most people were just getting up. The real game changer for me was requesting to reduce my working week to a 3-day week. This gave me 2 full days a week to work on Bookey and is the main reason I managed to get the website finished. Finding time and energy is one of the most challenging aspects of starting up a project and it requires some creativity and an understanding of how you function to get it right.

2. Spreading the word on a shoestring budget

Promoting Bookey and getting the word out has been one of the hardest parts of this project. We’re not made of money and don’t have financial backing to spend a large amount on an advertising campaign. This has left us in a bit of rough spot as we’ve had to rely on word-of-mouth and our own network to grow the users of the app. There are ways of marketing on a shoestring budget but they are incredibly difficult to get right. If you don’t have a large budget, you need to think about how you can spread the word without paying. One strategy we tried out was to give users the option to invite friends on Bookey. If you can convince your users to invite two friends each, you’re going to start seeing viral growth. However, it’s difficult to give your users enough of an incentive to go through the effort of inviting their friends. Uber is an amazing company but they still had to pay users £10 for them to invite their friends onto the app. We’re still trying to think of good rewards and incentives we could give to users to encourage them to invite their friends. If you have any good suggestions for this, we’d love to hear from you!

3. Progressive Web Applications vs Mobile apps

When I first started the Bookey journey, I was torn between making a website or a mobile app. I’d heard about Progressive Web Apps and there are a lot of strong arguments for making an app in this way. Here is a quick list of the key factors if you are deciding between a mobile app vs PWA:

PWA

  • A web app can be accessed by anyone with an internet connection but you need a specific mobile device for an iOS or Android app
  • Downloading an app takes time and effort which can be a barrier for unconvinced users but visiting a website is much quicker and you have greater control over their first impression of your app
  • iOS/Android apps leave you vulnerable to the rules set by Apple and Google. They often use their market power to bully smaller organisations and can set strict and arbitrary rules that can hinder your app. Google forced me to make some updates to bring my app in line with new rules that they had set. This was costly and it isn’t nice having to work to someone else’s schedule or risk having your app cut off.
  • Having a website is cheaper than having an app on the app/play store

Mobile app

  • Existing marketplace with large number of users with the (small) possibility of being featured on the app store and getting lots of attention
  • Slightly better performance
  • Ability to send notifications while the user is not using the app
  • Offline capabilities

For me, the benefits of the PWA are becoming more difficult to ignore and we have therefore decided to bring all of the functionality onto Bookey.org.uk. The iOS and Android apps are still being supported but we are now focusing most of our effort on the website to make Bookey even more inclusive than before. If you are moving from the app to the website, you will need to use an email to sign up. We had some issues with using Facebook login and they are a company we would like to avoid at all costs. They restricted our access to their platform because of a bug affecting some Android users and were very difficult to communicate with. Using APIs from other organisations can be useful but you should remember that it puts your application at the mercy of them.

2. Accessibility and device-agnostic websites

Websites these days need to be functional on a variety of devices. A quick analysis of Bookey on Google Analytics showed me that 60% of visitors were viewing Bookey on a mobile device. Making Bookey mobile and tablet friendly were time-intensive tasks but I’ve learned a few things that will speed up this task in the future.

The most important thing when it comes to responsive sizing is thinking about whether text or images will be the correct size when the screen size is different. You can’t just scale down a desktop design and expect it to work on mobile. I’d recommend planning out one design for mobile and one for desktop. You can try to make the designs quite similar so that you only need to make one React component with some media queries. However, this isn’t always possible and sometimes you might have to create a completely separate component for mobile devices. At Bookey, we used emotion as our css-in-js solution that allowed us to easily pass variables from JS to CSS and write media queries in a very simple fashion. I’ve used plain css and styled components and emotion wins hands down for me because of the concise syntax for media queries.

Here is an example of what my emotion code looks like. As you can see, some of the css properties can take an array of 4 arguments. The arguments correspond like so : [default, <500 px, 500–1025px, 1025–1400px]. I really like this way of doing media queries as it lets you see all the different styles in the same place as opposed to CSS usual method of forcing you to put the different media queries in different parts of the file.

const breakpoints = [500, 1025, 1400];const mq = facepaint([`@media(min-width: ${breakpoints.slice(0, 1)}px)`,`@media(min-width: ${breakpoints.slice(1, 2)}px)`,`@media(min-width: ${breakpoints.slice(2, 3)}px)`,]);const styles = {  topDiv: (color, animate) => css(mq({    display: "flex",    flexDirection: "row",    width: [300, '45%', '30%', '30%'],    color: color ? color : null,    maxWidth: [undefined, 400, undefined, undefined],
}))
}

A few other points about accessibility. Chrome dev tools are definitely your friend as it has many capabilities which are immensely useful. However, please be aware that it does not simulate a mobile device perfectly. When you’re testing the mobile version, do it using your mobile device. You can connect to your locally running app using your phone by just going to {Your_IP}:{PORT_OF_APP}. e.g in my case 192.473.53.53:3000. This assumes your phone and laptop are connected to the same wifi network.

A final note on different browsers. Different browsers behave slightly differently and one of the main differences that I had to tackle was the fact that Safari does not set the position property to ‘relative’ by default. This happens on Chrome but it is something you need to put in for Safari. There are a few other differences but this is the main one that came up for me.

3. On-boarding a junior developer

Adding inexperienced developers can be a tricky task to get right as they are inevitably going to make mistakes. However, they are often very motivated, can add a fresh perspective and their energy can drive forward a project.

The key to having a successful junior developer is setting them tasks of the right difficulty and understanding their motivations. People work best when they are challenged, able to learn and given some flexibility in how they perform their tasks.

I threw our intern, Sajad Jabarivasal, into the deep end with the challenge of developing front-end components before he had an adequate knowledge of CSS. This meant he often made mistakes or handed in work that needed to be amended. The solution to this issue is to check in with junior members as frequently as possible, especially at the beginning. Code reviews are very important and I’ve found that having small meetings to explain and talk through the reviews can make them stick more.

If you notice bad habits, place emphasis on these aspects and explain why this habit causes problems. Bad habits can take time to resolve and may need some investigating to figure out why the developer is so prone to making these mistakes.

The learn-on-the-job approach worked well for front-end tasks but it was less successful on the back-end. This may be because the back-end is conceptually more difficult and harder to learn by looking at existing examples.

One thing that worked really well was pair programming. This is something that can easily be done working remotely and it is a great way to transfer knowledge. I went about this by completing a dev ticket with my intern while describing my through process at every step.

4. Testing

Testing is something I have had a love-hate relationship with so far. I initially thought testing was a bit overkill and would slow down a young project too much. However, you can occasionally come across some bugs that are incredibly difficult to tackle without programmatic testing. The key is to identify these areas of your app beforehand.

On Bookey, front-end testing would definitely have slowed down the development process without adding much value. The areas that testing really become useful are on the more complicated database functions as well as functions that interact with APIs. These are the parts of the app that would take a lot of time to test manually and have many combinations that need checking. I think a consideration of how long it would take to test manually is a useful one when you’re trying to decide what to test. At previous companies, we had rules set to ensure 80% of lines of code had been tested. This would often lead to redundant tests and is not a good use of developer time. Trusting your developers is important and a better metric could be to analyse how many bugs appear in the code. If there are many bugs, that developer should be nudged into writing more tests.

I hope you found these tips useful and please enjoy the app responsibly!

--

--

Amir Jabari

Optimistic writer who is barely tethered to reality