Frontend – HadCoffee Blog

Category: Frontend

Posted on

Reworking the Fav and “To Try” Coffee List Feature

One of the main features of HadCoffee is keeping a list of your favourite cafes and the ones you want to try. Favs are useful when people ask for recommendations and you’re at risk of forgetting those dearest to you.

To Try is a good way to bookmark cafes to visit when you’re near them later.

Cafes can be added and removed from these lists with their UI controls. Initially these were only present on the cafe detail page, but over time I have included them on the search results listing and on the Cafes page.

To correctly show the status (i.e. whether a cafe is already on either of these lists) I needed to rebuild the local state to use Vuex. This means the icons can be rendered in multiple locations of the UI and show synced state. It also makes it far easier to deploy them in new UI sections later.

To support that data structure though I needed to do a refactor of the backend API which provides that data from the server. The API can be used to both list just the cafe ids for each list, or return more fleshed out object data for the features that render more complete cafe information.

UI screenshot diagram. Multiple Vue component with linked state

I’m happy with this final design. I can now place these controls wherever they need to go on the UI and they’ll initiate with state from the server, then manage it locally through Vuex. As a bonus you get a nice little page load animation with the star filling up and the list clicking on if the cafe is active on the list.

Posted on

Cafe Search Frontend Data Flow

Diagram of app search feature components. Location, input form and result output sections linked in Vuex

The home screen will let you search for cafes, either by location, or by cafe name (or the combination of the two).

Today I made good progress with the frontend flow of data to support this feature. The app uses Vuex for state storage. This feature has three different Vue components accessing related data to manage the users search.

The quick location search will use the browser geolocation feature as a default, and that data will flow through to the search form via Vuex. If the user is searching for a cafe by name that content will also go through Vuex for global access.

When the search event is triggered the results component can access this state, and send the API request to the server and build out the result set.

The event listening process was a little tricky, as state properties are accessed via getters, and so the normal method of capturing events and passing to component properties won’t work. A combination of Vuex getters, computed properties and watchers lets the result component listen for the search action to do its work.

I can now work on the backend logic for the API endpoint and build out the results data.

I’m a little concerned that that work could get heavy as this is almost a mini-SPA now. Possibly Livewire would have been a good solution, but I’m not going to introduce new architecture at this point in the project development.

I may have to consider how to cache the search result if the user navigates away and comes back. I’d prefer to avoid having to refetch from the server as that delay is annoying when it’s data you have already accessed. Worst case scenario I guess is to capture search criteria in localStorage, and cache the result server side so the response comes in <100ms.

Posted on

Rating by Type of Coffee

Not all cafes will make white, espresso or filter coffees equally, or equally well. Some might have a focus on espresso and bit a little average for the whites, or vice versa. Rather than combining all their ratings and losing that granularity I will let users specify what sort of drink they had when rating a coffee.

screenshot of coffee type UI
WIP UI for selecting drink types

I think this will be important to help give better recommendations. A cafe might do stellar cappuccinos, but if they’re ordinary at a Long Black and that’s what you’re going to order the Cap won’t help you!

The feature does add quite a bit of complexity to the development though. I need to start tracking ratings separately for the drink categories, as well as in aggregate. The scoring algorithm will also ideally weight itself towards a users history and preferences too.

It also has frontend implications with extra UI, state management and icon design requirements. The image above is still, but I am working on building subtly animated SVG icons for the drink types to enhance the UX of choosing them. I’ve got a nice little stepped animation to show the selection action.

SVG

I love the flexibility of images-as-code and being able to add simple animation effects with CSS. I am a little concerned that bundling the SVG icons into Vue components will be adding more weight to the final JS build.

I think referencing a static SVG as an image will prevent me from being able to style and animate individual shapes with CSS. It needs to be an embedded object. When I’m already deep in a Vue component structure that means the icon also needs to be a Vue component (as opposed to server side injected SVG code).

In my defence though, I think most of the audience who are into visiting specialty coffee cafes for entertainment probably err towards having high end phones that are capable of dealing with the load. The JS will be cacheable and probably even service worker cached in the future, so it’s more a CPU/parsing issue.

Backend

Most of the backend adaptations are still to be done though, and the actual search weighting will happen later as I build that feature.

Glad to be Moving to Vuex State Management

The growing amount of data stored for a rated coffee would get difficult to manage within a single parent component. I’m glad I’ve started the work of using Vuex to control the global state. Passing this many props and events up and down the component chain would be quite messy.

Overall Progress

So much of the project framework is complete, but there are a few key features left to build.

  • Drink Type management described here
  • Reverse geocoding and caching so the app can refer to your suburb/city and not just Lat/Long
  • The main cafe search feature, using that geographic information and drink preferences
  • Ability for users to add missing cafes at the time they are entering a review. (This can use some of the existing backend code I have already written from an admin perspective)
  • Service Worker / PWA bundling. This will be very minimal for now. Home screen, and basic asset caching, but no real offline support.
  • Performance and A11Y review

Posted on

Images

Coded a basic cafe banner image handler today.

  • Resizes to 2000px and 1000px variations
  • Creates WebP version for supporting browsers
  • Had to use GD for that, my install of Imagick didn’t have WebP support
  • File upload is sync, but resizing and cloud upload is Queued job so user doesn’t wait
  • Uploads to S3 and cleans up old file versions

The code that renders the image on the frontend cafe page is suuuper rough. Just gets a random size, rather than using srcset. Sniffs webp support and does cloud disk access right in the view. Definitely needs tidying up, still a good start though.

Sourcing 2000px images (wide on retina) might be difficult. A lot of photos on the web seem to be lower quality. Might have to ask users or cafes to submit a quality one!

Posted on

Ratings, Favourites, A11Y, SVG & Lists

I made a nice chunk of progress on the ‘To Try’ feature of HadCoffee this weekend. This lets you bookmark cafés you’ve heard of and would like to try later. By default the list on HadCoffee will sort by proximity using your current location.

Screenshot of list of cafes to try
The list, sorted by proximity taking into account that some cafes have multiple locations. The coffee cup icon shows the cafe’s rating, and the star toggles it on your Favourites list.

Most of the recent work for this feature was on some nice-to-use buttons for toggling a cafe in your Favourites or To Try list. I had mostly built the ‘Fav star’ earlier, but improved it with a visual :focus indicator for keyboard accessibility.

See the Pen SVG Favourite by Mike (@mike_hasarms) on CodePen.

The coffee cup icons are SVG based Vue components that receive rating data from the page and fill the cup appropriately.

I also worked on some basic animation of the button to add a cafe to the To Try list to make the transition to the active state a bit more obvious. I think little touches of movement make the thing more engaging to use as well.

screenshot of cafe action buttons
You can’t see it, but the last item on the ‘list’ animates in when clicked.

Accessibility

I spent a bit of time improving the A11Y of these (and other features). The Vue SVG components are keyboard accessible, labelled and indicate focus. I am planning to do a more thorough A11Y test before I release, but I’m certainly not leaving all of those concerns until the end of development.

Anonymous Users

Currently the Favourites and To Try lists require a user to be logged in. I had planned to allow anonymous users to begin keeping these lists for themselves in localStorage. The idea was to lower the barrier to entry to using the site. It does however add development complexity as the app needs to be able to use both local and server storage for those lists and load in data in different ways.

As this is a mostly server-rendered app all the initial page data is sent down with the page load, and populated into the Vue components. Supporting anon users will require separate logic to request their cafe data from an API endpoint.

That’s not hugely difficult, it’s just another thing to be done before launch.

Posted on

Cafe Suggestions with Geo Search

I’m keen to make some solid progress on HadCoffee over the Christmas period to hopefully get to an early 2019 v1 launch. This week I was working on the main coffee rating interface which depends on users being able to select or enter the café they visited.

I’ll add the autocomplete lookups for typed cafe names, but I also wanted some basic quick suggestions based on where the user has been before and their current location.

This would save typing for common places and maybe also hint at other nearby cafés the user mightn’t know about.

The frontend part of these feature went pretty smoothly. The Vue component watches for the users location (HTML5 Geolocation) and calls the backend to load these quick suggestions as it’s known. There’s a little debounce action to slow things down as the geolocation API can return updated positions in quick succession as it locks on a more accurate location.

Geographic Search by Proximity

The smooth progress I was making through this feature hit a wall when it came to actually querying cafés by distance though. I was hoping to use MySQL’s ST_Distance_sphere function to let the DB do that work. I’m running MariaDB though, which although it’s advertised as a ‘drop in’ replacement for MySQL does not support this feature ????

I prefer a simpler dev environment (I’m not using Laravel Valet or Docker images) so I didn’t feel like swapping to MySQL for this project. Changing my workflow to use Valet also wasn’t very appealing when I’m otherwise happy with the setup. so I briefly tried migrating to Postgres. I know it’s a great DB, but I haven’t used it before and that’s a big change to have to make to run one type of query.

In the end I’m going with a raw SQL query to help with this. I’ll add a simple bounding box to its parameters first to avoid having to do a table scan of every cafe in the world (once my DB gets to that point ????)

Although it took a windy path this geo search will also provide the basis for the other cafe search features on the site such as the autocomplete (to improve relevance) and the location based search.

$query  = "SELECT id, cafe_id, lat, lng, address, locality, city,
        ( 6371 * acos( cos( radians(:lat) ) * cos( radians( lat ) ) 
        * cos( radians( lng ) - radians(:lng) ) + sin( radians(:lat2) ) * sin(radians(lat)) ) ) AS distance 
        FROM cafe_locations ";

This is a good step towards being able to add café & coffee reviews, however the next big sticking point will be letting users add new cafés as they go.

Ideally I’d like to collect a bit of meta data such as roasters, menu and seating options to help users finding cafés, but I’ll have to see how much data entry users will tolerate. I also need to be aware of how or if I can verify this community sourced data.

Posted on

Designing, Decisions and Scope Creep

Photos – I’ve started to think they could be important for helping a user know if a cafe has the vibe they’re after. Implementing them does open a whole new bag of onions with regards to uploading, deleting, featuring, moderating, offloading, resizing and such.

I’m not sure if that should end up in the v1 release or if I’m just blowing up the scope unnecessarily. I’m not trying to be Instagram, but at the same time photos do tell a story of what the place is like.

Cafe Views in the Frontend

The HTML/CSS for a cafe view in the frontend are coming along. The placeholder data and characters need to be replaced with real components, but I do have the offset height panels and slanted shadow that I was after.

Seeya flat design, it’s been nice, but I need a break for a while.

Posted on

Frontend Dev Progress

I’ve made some progress on the frontend interfaces for logging a coffee/rating a cafe and the cafes section for managing your preferred cafes.

Screenshot of UI to Add a coffee
Work in progress built UI

The coffee counter cup is now a working Vue component. The proportions will need a little bit of media query love to work at different sizes, but the main features of the interaction, the long shadow and the chamfer curved buttons are all in place ????

The Cafe component of this UI will need a reasonable amount of backend work to function in order to auto-suggest cafes based on name and location.

I’m hoping that allowing users to enter new cafes not yet in the DB will be fairly straight forward. There’s a chance that managing duplicate or incorrect data could require additional processes beyond standard CRUDing. We’ll see.

My Cafes

My Cafes UI progress

This is my first use of Vue Router to provide a semi SPA type structure to this page. The Recent / Favs / To Try links are Vue Router links which dynamically swap out the component below for the appropriate content. Vue Router handles updating the browser URL to maintain back button functionality. I had to put a bit of work into detecting the current route in order to swap out the icon SVG symbol. All the icons on this screen including the active state color versions are referenced from a single SVG sprite.

I’m really happy with this approach for both performance and maintainability reasons. I can create different color variations of symbols directly in the SVG code without needing to use Sketch.

To lower the barrier to entry for using HadCoffee.com I’d like to allow anonymous users to be able to save cafes to their favs/to try lists as well. I’d likely just store cafe ids in localStorage and expand that data from the server.

Signed up users will have the more robust backend storage of all this data.

Posted on

Some Development has Happened

I did some frontend dev. Specifically a Vue Router implementation to navigate Vue components on the Cafes section, with fancy SVG icons ????

I might break out some code for a demo one day. Or just keep working on HadCoffee instead, not sure.