The Hooks of React Router

React Router 5 embraces the power of hooks and has introduced four different hooks to help with routing. You will find this article useful if you are looking for a quick primer on the new patterns of React Router. But before we look at hooks, we will start off with a new route rendering pattern.

Before React Router 5

// When you wanted to render the route and get router props for component
<Route path="/" component={Home} />


// Or when you wanted to pass extra props
<Route path="/" render={({ match }) => <Profile match={match} mine={true} />}>

When using the component syntax, route props (match, location and history) are implicitly being passed on to the component. But it has to be changed to render once you have extra props to pass to the component. Note that adding an inline function to the component syntax would lead to the component re-mounting on every render.

After React Router 5

<Route path="/"> <Home />
</Route>

Note that there is no implicit passing of any props to the Home component. But without changing anything with the Route itself, you can add any extra props to the Home component. You can no longer make the mistake of re-mounting the component on every render and that’s the best kind of API.

But now route props are not being passed implicitly, so how do we access match, history or location? Do we have to wrap all components with withRouter? That is where the hooks steps in.

Note that hooks were introduced in 16.8 version of React, so you need to be above that version to use them.

useHistory

  • Provides access to the history prop in React Router
  • Refers to the history package dependency that the router uses
  • A primary use case would be for programmatic routing with functions, like push, replace, etc.
import { useHistory } from 'react-router-dom'; function Home() { const history = useHistory(); return <button onClick={() => history.push('/profile')}>Profile</button>;
}

useLocation

  • Provides access to the location prop in React Router
  • It is similar to window.location in the browser itself, but this is accessible everywhere as it represents the Router state and location.
  • A primary use case for this would be to access the query params or the complete route string.
import { useLocation } from 'react-router-dom'; function Profile() { const location = useLocation(); useEffect(() => { const currentPath = location.pathname; const searchParams = new URLSearchParams(location.search); }, [location]); return <p>Profile</p>;
}

Since the location property is immutable, useEffect will call the function every time the route changes, making it perfect to operate on search parameters or current path.

useParams

  • Provides access to search parameters in the URL
  • This was possible earlier only using match.params.
import { useParams, Route } from 'react-router-dom'; function Profile() { const { name } = useParams(); return <p>{name}'s Profile</p>;
} function Dashboard() { return ( <> <nav> <Link to={`/profile/ann`}>Ann's Profile</Link> </nav> <main> <Route path="/profile/:name"> <Profile /> </Route> </main> </> );
}

useRouteMatch

  • Provides access to the match object
  • If it is provided with no arguments, it returns the closest match in the component or its parents.
  • A primary use case would be to construct nested paths.
import { useRouteMatch, Route } from 'react-router-dom'; function Auth() { const match = useRouteMatch(); return ( <> <Route path={`${match.url}/login`}> <Login /> </Route> <Route path={`${match.url}/register`}> <Register /> </Route> </> );
}

You can also use useRouteMatch to access a match without rendering a Route. This is done by passing it the location argument.

For example, consider that you need your own profile to be rendered at /profile and somebody else’s profile if the URL contains the name of the person /profile/dan or /profile/ann. Without using the hook, you would either write a Switch, list both routes and customize them with props. But now, using the hook we can do this:

import { Route, BrowserRouter as Router, Link, useRouteMatch,
} from 'react-router-dom'; function Profile() { const match = useRouteMatch('/profile/:name'); return match ? <p>{match.params.name}'s Profile</p> : <p>My own profile</p>;
} export default function App() { return ( <Router> <nav> <Link to="/profile">My Profile</Link> <br /> <Link to={`/profile/ann`}>Ann's Profile</Link> </nav> <Route path="/profile"> <Profile /> </Route> </Router> );
}

You can also use all the props on Route like exact or sensitive as an object with useRouteMatch.

Wrapping up

The hooks and explicit Route comes with a hidden advantage in itself. After teaching these techniques at multiple workshops, I have come to the realization that these help avoid a lot of confusion and intricacies that came with the earlier patterns. There are suddenly far fewer unforced errors. They will surely help make your router code more maintainable and you will find it way easier to upgrade to new React Router versions.

The post The Hooks of React Router appeared first on CSS-Tricks.

How To Book More Appointments And Events With A WordPress Booking Plugin

How To Book More Appointments And Events With A WordPress Booking Plugin

How To Book More Appointments And Events With A WordPress Booking Plugin

Suzanne Scacca

2020-02-11T12:00:00+00:00 2020-02-12T00:36:00+00:00

When it comes to running a service-based business online, scheduling appointments with prospects and clients is critical. The downside of that, of course, is that it takes a lot of time to manage appointments and event bookings if you do it on your own.

With WordPress, however, there are a bunch of booking plugins that’ll get the job done. Put one of them in place and you can kiss many of those tedious appointment management tasks goodbye.

But all this is contingent on using the right WordPress booking plugin.

Today, I’m going to introduce you to the Amelia appointments and events WordPress booking plugin. But rather than show you how to install and use the plugin (which is very easy), I want to spend this time showing you how to design an effective booking system using it.

How To Book More Appointments And Events With Amelia

There are many kinds of clients that would benefit from a booking system:

  • Salons, spas, fitness centers with services or classes at specific times;
  • Service providers that work by appointment only (e.g. mechanics, plumbers, etc.);
  • Real estate agents that host open houses or schedule property walk-throughs;
  • Companies that put out webinars, virtual classes and so on;
  • Freelancers and small businesses (like yours) that use discovery calls to vet prospects.

Now, they could use a third-party reservation system, but they’re often costly and difficult to manage. Not to mention the fact that some of these systems aggregate competitor listings. This might make it more convenient for the user to sift through a number of options at once, but this kind of booking system is just begging to pull prospective customers’ attention away from you.

By building a booking system right into your client’s website, you can avoid all of these possible issues. What’s more, you can automate the tedious tasks they would have resorted to doing on their own without a proper booking system option. For instance:

  • Capturing prospects’ correct contact information.
  • Figuring out a day and time that works best for both parties.
  • Managing reschedules and cancellations.
  • And more.

Consider how grateful your clients will be if you build a booking system that relieves them of this time-consuming burden.

That said, there’s more to creating a WordPress booking system than just activating a plugin and embedding a shortcode. To help your clients effortlessly capture more appointments and events with the Amelia booking plugin, you’ll need to do the following:

1. Add Search And Filter Elements To Reduce Decision Fatigue

This won’t be the case for every booking system, but for businesses that offer a variety of options, appointments, service providers and so on, reducing decision fatigue is very important at this stage.

Take, for instance, a spa or salon website:

Appointment booking buttons
An example of how you might present appointment and event bookings to customers on a WordPress website. (Source: Amelia) (Large preview)

Many times, these kinds of businesses have a multitude of services (or on-site events) they offer. You could let your visitors click on “Book Appointment” or “Book Event” and sort through every service offering and provider on their own. Or you could improve the process by adding a search bar to your booking widget like this:

Amelia appointment search
Amelia booking widgets enable customers to quickly search for a service or provider. (Source: Amelia) (Large preview)

The sidebar filters also help — especially if customers aren’t necessarily sure what service they need or what it’s called. The pre-populated options make it easier to make those on-the-spot decisions.

In this example, the spa allows customers to filter services by:

  • Appointment Date,
  • Time Range,
  • Services (which are all visible and multiple options can be selected),
  • Employees.
Amelia booking filters
Amelia booking widgets enable customers to use filters to look up services and providers. (Source: Amelia) (Large preview)

This is a great example of how you can decrease decision fatigue with just a few design tweaks and help users book appointments more confidently and quickly.

2. Shorten The Signup And Sales Process

Think about the use case for your own business (as well as services providers like yourself).

Let’s say you want to set up an appointment scheduler for web design discovery calls. Wouldn’t it be useful to allow prospects to upload files when booking their appointments? They’d be able to share important documents like their style guide, logo and even their content before the appointment takes place.

As for how you build this into the booking widget, it’s fairly straightforward with your WordPress appointment plugin.

By default, Amelia allows you to control essential details about your “Events” and “Services”:

  • Name of the event,
  • Date and time options,
  • Recurring schedule,
  • Booking time period,
  • Staff available,
  • And so on.
Create a new event or service in Amelia
Creating a new event or service with the Amelia plugin is easy. (Source: Amelia) (Large preview)

To allow prospects to upload files, you’ll need to go to the “Customize” tab and create a custom field for it:

Amelia Custom Fields
To enable users to upload files, use Amelia Custom Fields. (Source: Amelia) (Large preview)

Click “Add Custom Field” and you’ll see an option for “Attachment”:

Amelia file attachment field
Add a file attachment field to your booking form with Amelia. (Source: Amelia) (Large preview)

All you need to do is give the new Attachment field a label (so people know what to upload) and then add it to any service or event you want it to appear in the booking widget for:

Amelia file attachment customization
Customize the file attachment field so that users see it at the right times and know what exactly to upload. (Source: Amelia) (Large preview)

On the front end of the site, the new Attachment field will look like this:

Amelia booking file uploads
Amelia booking widgets enable customers to upload files at the time of booking. (Source: Amelia) (Large preview)

It’s intuitive in design and, so long as you label it well, your users should find this additional field (required or not) one they want to take advantage of — especially if it means less work later.

For your own purposes, think about how great it would be to have a form like this in your appointment scheduler.

This would allow you to come fully prepared to the meeting rather than have to devise a rough plan on the spot. It would also shorten the lifecycle of your projects as you wouldn’t have to sit around waiting for clients to deliver essential documentation and content. (This would also be useful for people like healthcare practitioners or lawyers who need special waivers before they can take on new patients or clients.)

Plus, prospects that are this prepared in the initial booking stage are the kind of clients you want to be working with, so think of this feature as another way to vet your prospects (and help your clients do the same).

3. Make The Booking Widget As Effective As A Personal Assistant

Even if your clients aren’t the ones actually taking and managing appointments for their businesses, they have an assistant who is. While that’s a useful resource to have for this task, humans are prone to errors — especially when trying to capture someone’s contact information over the phone. (I can’t tell you how frequently I show up to appointments or reservations with my name misspelled or email written incorrectly).

Your WordPress schedule plugin, however, captures this information exactly as your users input it. So long as they don’t introduce any errors themselves, this will greatly improve the accuracy of your bookings.

So, what can you do to turn your booking widget into a digital personal assistant?

Obviously, including an intuitive form with well-labeled fields will be a huge help. But you have to think beyond that. There are things a human assistant would do, like cross-reference requested appointment times with actual availability as well as add buffer times between appointments, that improve the experience for all.

You can program the Amelia booking plugin to do the same.

For starters, create custom schedules and booking parameters for each service offering or event.

Amelia customize appointment times
Create custom appointment date and time options for each event or service. (Source: Amelia) (Large preview)

This is useful for a number of reasons.

For one, it ensures that customers only book on days and times when an appointment is available. In addition, it allows your client to control how many customers show up to events, classes, services and so on. That way, even if the 12-to-1 slot is the most popular time (because that’s when everyone’s on lunch), your client won’t get overwhelmed with appointments and be unable to serve everyone who booked at that time.

If appointments are booked with certain employees or providers, that’s another layer of complexity that should be accounted for in the design of your booking widget.

When setting up a new Employee option in Amelia, don’t just focus on the superficial stuff like who they are and which services they provide.

Amelia service provider schedules
Set custom schedules for employees and service providers in Amelia. (Source: Amelia) (Large preview)

Set specific work hours, days off and holidays when they’re available. That way, users won’t be tempted to book their favorite provider when they aren’t around. They’ll only see the date and time options that are open.

Another thing you can do to improve the accuracy of bookings is by building buffer times around them.

Buffers give your clients and their teams time to:

  • Properly set up for upcoming appointments (e.g. brushing up on a prospect or setting up a virtual conference room).
  • “Clean up” after an appointment (e.g. physically cleaning up the surrounding space or capturing notes from a call).

It’s also a good idea to have buffer times in case there are overzealous prospects or customers who just want to talk and talk and talk or otherwise push the appointment over the allotted time. By having a buffer in place, it can help keep other customers’ appointments from starting late and, thus, starting the experience off on the wrong foot.

Under each Service you’ve created in Amelia, you have the option to add a buffer time before and after the time slots:

Amelia appointment buffer times
Add a buffer to appointment times in Amelia. (Source: Amelia) (Large preview)

Definitely make use of this so you don’t end up creating more work or headaches for your client in the end.

Oh, and if it’s just a solo provider you’re building this appointments system for, you don’t have to set up all of these individual schedules or buffer times. You can create universal scheduling rules from the Settings tab.

4. Collect Payments At The Time Of Booking

No matter how much you do to ensure that appointments can easily be booked by customers and managed by your clients, that doesn’t stop customers from flaking out on appointments.

You’re probably aware of what kind of effect this has in your business. When someone’s a no-show, you’re left sitting around waiting for them to hop onto Zoom or Skype. You give it 10 or 15 minutes before shooting off an email to reschedule and then you get back to work. Another consequence is that you’re now left with an opening that could’ve been filled by another interested prospect (and new source of revenue).

Whether your clients are booking online events or in-person appointments or classes, they experience a similar kind of time-waste and profit loss. So, to encourage more customers to actually attend their bookings, you can set up the scheduler to collect payments upfront.

The first thing to do in Amelia is to add a price to all of your services and events. Even if you don’t plan on charging upfront, this is a good idea anyway as it reminds customers what they’ll owe in the end.

Amelia service price
Set per-service or per-event prices in Amelia. (Source: Amelia) (Large preview)

To take it to the next step, enable payment collection and set up a payment processor (either Stripe or PayPal). You’ll find this under Amelia’s “Settings” and “Payments”:

Amelia payment processor setup
How to configure your Amelia booking plugin to accept payments for appointments. (Source: Amelia) (Large preview)

When this setting is enabled, customers will automatically be taken to your payment processor after clicking the “Confirm” button on their appointment:

Amelia appointment confirmation and payment
When customers ‘Confirm’ their event, they’ll be asked for payment. (Source: Amelia) (Large preview)

So, one thing I would advise is to include a note in the form — somewhere around the price — to let them know that payment will be collected now instead of when the service is rendered.

You could also use this for a business like your own by charging a small fee or retainer for the initial discovery call.

Another thing you can do to ensure that clients don’t lose potential revenue from missed appointments is to integrate the booking system with an external CRM or email marketing software. That way, you’ll capture users’ contact information outside of WordPress and can set up automated follow-up messages if or when they miss an appointment.

It might not help your clients recapture all of that missed business, but it’ll help restore some of it.

There are two ways to set this up. The first is using the Web Hooks Settings in Amelia:

Amelia Web Hooks
Use Web Hooks in Amelia to connect booking system to other platforms. (Source: Amelia) (Large preview)

If a customer cancels, reschedules or otherwise changes their appointment, you can trigger the plugin to send that information to their third-party software. And with other automated events set up (like to invite a customer who canceled to reschedule a couple of weeks later), your client won’t have to do much to try to reconnect with the customer. Think of this as a cart abandonment feature, only for appointments.

You can also use Zapier integrations and webhooks to do the same thing.

5. Automate Emails And SMS

While it’s important to try to recapture potentially lost business with follow-ups, they’re not the only customers your booking system should be in contact with. All customers matter.

As such, you should use automated emails and SMS to:

  • Send a confirmation email with all the details of a booking to a customer (in addition to an .ics file that enables them to quickly add it to their personal calendar).
  • Set up the same confirmation messaging for employees to notify them when they’ve been scheduled.
  • Remind customers of an upcoming appointment with options to reschedule (or cancel) if they can’t make it.
  • Send a “thank you” after the appointment is done. In some cases, you may invite them back for another one. In other cases (like your own), you could use this to send information on next steps.
  • Email them to wish them a happy birthday, congratulate them on an anniversary or celebrate some other special day (perhaps with a goodie inside).

Bottom line: While you can certainly wow customers during a booking, you can sustain that wow for much longer by showing that it’s not just about the exchange of time and money at the time of the appointment. And that you really appreciate their business and loyalty.

With Amelia, a lot of this work is done for you already:

Amelia appointment notifications
The Amelia plugin comes with pre-made and written customer appointment emails and SMS. (Source: Amelia) (Large preview)

Common email and SMS notifications have already been created and written for you. Even better, they included personalized placeholders so messages don’t have to go out to customers sounding cold and detached.

If there are any messages not included that you want to automate, you can use your Zapier integration and third-party marketing software to handle that piece. However, what’s included here is pretty robust and covers all the bases when it comes to managing appointments.

Wrapping Up

You know how tedious and time-consuming it is having to manually manage your own appointments and events. Worse, the manual approach increases the risk of error, either losing track of the appointment altogether or not capturing details correctly and never being able to connect with the prospect as intended.

But with the help of the Amelia appointments and events WordPress booking plugin, you can automate a ton of this work. Not only that, you can elevate your booking system so that more prospects are encouraged to sign up.

Smashing Editorial (ms, ra, yk, il)
Smashing Podcast Episode 9 With Stéphanie Walter: How Can I Work With UI Frameworks?

Smashing Podcast Episode 9 With Stéphanie Walter: How Can I Work With UI Frameworks?

Smashing Podcast Episode 9 With Stéphanie Walter: How Can I Work With UI Frameworks?

Drew McLellan

2020-02-11T05:00:00+00:00 2020-02-16T01:08:21+00:00

Stéphanie WalterAs a developer myself, one of the things that I like about UI frameworks is that they often come with default styling, but is that something that we should be relying on in projects? Simply using the default styling and trusting that whoever produced the framework has done a really good job in designing those components? Join me for today’s podcast episode where I speak to UX Designer Stéphanie Walter about things we should be considering when building on a UI framework.

Show Notes

Weekly Update

Transcript

Drew McLellan: She’s a user centered designer and expert in mobile experience, who crossed delightful products and interfaces with a special focus on performance. She’s worked on projects for clients such as the University of Luxembourg, European Investment Bank, BMW and Microsoft to name but a few, and she helps those clients deliver successful projects to their audience all the way from strategy to the final product. She’s a Google Developer expert in product design and a passionate teacher sharing her knowledge in numerous blog posts, articles, workshops and conference presentations. So we know she’s an expert user experience designer, but did you know she once had a job fitting carpets with Sir Elton John? My Smashing friends, please welcome Stéphanie Walter. Hello Stéphanie, how are you?

Stéphanie Walter: Hi, I’m smashing and loved the introduction.

Drew: So I wanted to talk to you today about a particular issue and that’s the subject of using off-the-shelf user interface frameworks. Now you’re a user experience designer and you work with lots of different clients and your job is to help those clients create the best possible user experiences through crafting highly usable user interfaces. So the idea of being able to do that with an off-the-shelf set of tools seems like a bit of a stretch to me. Is the use of UI framework something you see a lot throughout your work?

Stéphanie: Yeah, it’s something I’ve seen a lot, especially in the last few years because I started working with an agency and now I work within the company. So in those super big IT tech teams and yeah, at the moment there’s a lot of framework UIs like the one that I’ve seen the most is Material-UI, basically Material design is a Google design kind of guidelines and thing, and Material-UI is the team from Angular, but also the team from React. They created their own framework using kind of the look and feel of the Material design from Google. But it has nothing to do with Google anymore. It’s just like they, I don’t know, I think they liked the look and feel. So at the moment, those are the two main UI framework I work with. And also there’s something called Ant Design, that’s grew quite popular.

Stéphanie: It’s a React framework. I don’t know if they have Angular too. I think it was made by a team in China. And it’s interesting because not only does it provide the components, everything in React, but if you go to their website you’ll also get the scratch files, which is actually quite interesting because then it kind of motivates or helps the designer build or shape the interface into the UI components used by that framework. So yeah, it’s something I’ve seen a lot, especially in big IT teams because most of the times those don’t have a designer. At the moment I’m basically UX team of one in a small team at a European investment bank. So it’s me as a UX designer. I work with a team of developers, business analysts, all the good people, but still is one designer for the whole project.

Stéphanie: Until I arrived there was no designer. So it’s kind of a solution implemented in a lot of companies, especially on internal products for instance. Where they usually say, okay, we don’t really need a designer for that. We just need something that works for our internal users and let’s just use a framework because it’s convenient for the developers. Most of the components are already there and since they don’t have designers in the team, then it’s kind of replacing, as to say, the role of a UI designer. Yeah, problem with that is that, okay, then you have the components, but the role of the UI designer is not just to decide about should the button be red, green, orange, blue, whatever. Usually the role of the UI designer is information architecture, understanding user needs. So everything that goes beyond the interface. So even if you have this kind of framework that kind of takes care of the whole UI, So visually what you see on the screen.

Stéphanie: You still need someone at some point to do the job of understanding what do we put on the screen, how is it going to behave? What happens when we click here? How does the user accomplish their goal? How do we go from point A to point B? Because we can use a model, we can use tabs, we can use all of the components. So that’s why it’s always kind of a little bit complex and tricky.

Drew: Is it possible, do you think be able to create a usable user interface using an off the shelf UI framework, or is it always going to be a bit of a compromise?

Stéphanie: I kind of hope so. I kind of hope so because otherwise I’m building not usable interfaces. So this answer is totally biased, but yeah, I think it is, but it also depends on the level of compromise you’re willing to do and there’s compromises on both sides. At the moment I’m compromising a lot of buttons for instance, because you have some really specific buttons in Material-UI, and I don’t really like the ripple effect on the button. I think it works great on mobile because on mobile you need a kind of a big feedback when user clicks on or touches the button. But then the steps is kind of ripple effect that goes all the way on the button. It’s a little bit overkill, especially when there’s a lot of button. But still we are going to keep this ripple effect because it would be super complex to remove it because this was built in to the React framework. And to have another hover effect on this button, something more subtle that will not be this kind of whooshy thing here. It would be super complex.

Stéphanie: So this is the kind of compromises you do. But on the meantime, I don’t compromise on specific things which is custom components. Where I was working before, the current client for a travel and airline company. And airline has some really, really super specific needs. The calendar for the airline for instance, you want to put prices, you want to put… if you don’t travel to this destination on a specific date, you don’t know when to put that, you have this departure and arrival and the basic calendar of most of those UI frameworks don’t provide these kind of things. So at some point you can say, okay, we will just use the calendar they have. And that’s it. You need to go beyond that. So most of the compromises are basically built on, do we use the basic component? Do we create a custom one that will fit the user needs? Or do we make a mix of the two? In the case of the calendar, for instance, we use the calendar grid, so we use the basic component and then we enhanced it with customization on top of that. So it was a lot of React development for that one.

Stéphanie: And yeah, so usually you do a lot of compromises.

Drew: So it sounds like using a user interface framework can get you a certain amount of the way there, but to really have a good user interface as a result of it, you need to do quite a bit of customization on top?

Stéphanie: Usually. Yeah.

Drew: Does that customization go beyond theming?

Stéphanie: Yeah, my developer wished it wouldn’t go beyond theming. Eugene If you listen to me. I think he would be super happy if we would just change a few colors on everything. But yes, at some point you need to go beyond the customization because first, like UI frameworks are like Lego tools is kind of a toolbox. So you have a lot of different components in the box, but this doesn’t build a page. You still need a header, you still need a footer. You still need extra content that was not in the framework. So sometimes you can tweak a component into what you needed. From what I understood, we are using the card component to build a modal windows, but the thing with the modal windows is that it doesn’t really behave like a card.

Stéphanie: You are kind of going a little bit beyond that. You need a background with obscurification. You need to trigger it on click while usually your card is already there in the interface. So we are using this card component because it has a lot of the things we need like the background, a header and a title at the top, some buttons at the bottom. So we have the structure and then we tweak it a little bit. But we end up with some conflict sometimes about semantics, HTML as well. Because for instance, I wanted to have buttons that didn’t have button shapes, so just like link button and the developer said, “Okay, so we use a link like your href link.” I said, “No, this is not a link. It’s a button. When they click it, it doesn’t open a new page. It clears everything that is into the form.”

Stéphanie: So it should be technically from a semantical point of view, it should be a button. “Yeah. But it doesn’t exist in the framework.” I say “So okay, I know so what do we do?” So usually you start discussing these little things and since I’m really annoying my developers with accessibility also, this is another extra layer of trying to make sure that we have the basic components that they work well with. But also that they are semantically like I don’t want to have buttons with gifs within gifs within gifs. Otherwise we’ll have issues in the end.

Drew: I guess starting a new project that’s going to use a UI framework, you probably need to start with some sort of user research.

Stéphanie: Yes.

Drew: Is that fair?

Stéphanie: You should. You need to. So yes, usually you can have all the components you want. You still need to know what do your users need on the pages, how are they going to navigate? You need to build a flow. So usually even before deciding on a framework, what we do is we go to our users, we talk to them, we try to understand their needs. So at the moment I’m quite lucky because the users are internally within the bank. So we do a lot of workshops with them and you have to imagine it’s a super complex interface. We are migrating from something that was built, I don’t know, I think 10 or even 15 years ago to something all new shiny using Material-UI React. So it’s quite a big change and you have to understand that during those 15 years, everyone who wanted something could go to the support and then they ask the IT team to implement it. So at the moment my interface is like 400 pages with tables, within tables, within tables, with other tables, and stuff that shouldn’t even be in tables.

Stéphanie: Like we have a lot of things that are just key value, key value, key value. So they build the table with two columns. I’m like, “Nope, maybe we can do something better with that.” So at the moment what we are doing is we did some user research to understand the different goals of the users. So what we identified is that what they do with the interface, they have some planification goals. They need to plan their work. So I want to know that this operation is going to go to this meeting, so I need that on that schedule, stuff like that. They want to monitor a thing, they want to report the data. So monitoring is just like looking at the data and making sure everything is fine. Reporting is being able to exploit the data, to do something with it they want to share and to kind of collaborate with colleagues and all of that we discovered by discussing directly with the users.

Stéphanie: And what we discovered is that actually some of the things we were planning on migrating at the end are some of the most important things on a daily basis for the user. So the planification user goal is one of the kind of biggest one at the moment. So we are really, really working on that. So yeah we do use the interview and now we are in the phase where at the moment we are super high level saying okay we need to build the shell, we need to understand navigation. But at the moment we didn’t really go through all of the data and this is now what we are going to do. And it’s interesting because we have a lot of tables and we said we can either go the kind of not smart way and just put the tables in the new interface and we’re done, or we can say, okay, let’s try to understand what those tables are, What do our users use this table for?

Stéphanie: And then maybe some of the tables could be displayed as data visualization and then to do that you need to understand the whole business So that the data makes sense. So if you have a nice framework and you say, okay, let’s use this chart… I think is called chart JS framework. You have a lot of things, you can have histogram, pie charts and graphs and everything, but at some point you still need a designer to help you decide. Okay, this data, does it make sense if we show it into a graph or it makes more sense to show it as a pie because we want to show part of the whole, or we want to compare evolution for one country in the last 10 years, then a histogram is more interesting. So based on what the user wants to do with the data, you are going to display them a whole other way.

Stéphanie: And usually it’s not a developer job to do that. Our developer, they’re super smart guy. I’m sorry, but I honestly work with guy developers, I wish I had some ladies, but no. None of them are women. So super smart guys but they are not super qualified to say, okay, this data should be displayed like that, that, that and that. So in the end you still need some designers go to talk to the users, understand what you can do with the data and this goes far beyond just saying, okay, this should be a tab bar or this should be a navigation on the left.

Drew: And after making those sorts of decisions based on talking to the users. Would you typically take the resulting prototypes or designs back to users to test them again to see if they understand your type of chart choice for example?

Stéphanie: Yeah, we did that a lot actually, which is really nice because then you don’t develop something until you know it’s going to be useful and usable. So it depends. If it’s quicker to actually develop the thing because they have already most of the components, what I usually do is I do really quick paper prototyping and then we develop the thing because it’s quick, even without the data. If it’s something complex, something really, really new that will take a lot of time to develop, then we say, okay, we design a few screens and we do some testing directly on the screen. So we have a tool it’s called InVision, where basically you put all of your design, you can create links between the different parts. The thing is it also depends what you want to test. If you want to test phones for instance, it’s a nightmare to test those in InVision because the people can’t really feel them and especially on mobile phone for example.

Stéphanie: So it’s always kind of being smart. What’s the fastest and cheapest way? Is it faster and cheaper to test only designs. Is this enough? For forms usually, not really because you have auto completes all of the heavy lifting you put in the front end who have actually the user fill a form so for forms, maybe it’s more efficient to actually build a form and test it. But for new things, yeah, we do a lot of designs. We go to the users. So at the moment we either do one-on-ones, but my users are really busy people. It’s a European investment bank so they don’t have that much time. So what we usually do is that if we come to one-on-one with the users, we do some small meetings, like more like focus groups. And it’s also interesting because then you have kind of a confrontation sometimes. Some people say, “Yeah, I think it works for me because I work like that and that,” and then there’ll be other people who are like, “Oh you work like that? Actually no, I do it like that and that.”

Stéphanie: So it’s also interesting to kind of have a few people in the room and to listen just to the conversation, taking notes and say, “Oh maybe then we could do that” and “This component would be better based on what I just heard.” And things like that.

Drew: If you’re working with a more general audience for your product. So perhaps not internal users like you have, but more the general public, are there inexpensive ways that designers can get that use of research in? Are there easier ways if you don’t know directly who your users are going to be?

Stéphanie: You should know who they are going to be otherwise it does the job of the marketing people before building the product. But yeah, we did some guerrilla user testing for instance, You can still use InVision for instance. So you can build some prototypes in InVision and then you can recruit the users through social media, for instance. I was working for a product that helped, what is the name, car dealerships mechanics who repair things and then to also inform the client about extra repairs, things like that. So we had already kind of a growing community on LinkedIn and Facebook. So what you can do is you can recruit those people. You can do remote testing, like we are having conversation in a tool like an online tool. You can do some screen sharing. So we did that for some project also.

Stéphanie: I would just give you one advice is test the tool before, because I was using, it was called appear.in. But I think they changed the name to Whereby or something, but it’s really in the browser who I said, okay, it’s nice because then the users don’t need to install anything but do users were not on a real computer. They were into VM, into a Citrix and they didn’t have microphones so what we ended up doing is like they used my tool to share the screen. They were clicking on the prototype and at the same time I had them over the phone, like a landline phone, to talk to them directly. So there’s always, this was a quite cheap because it was a wonderful day of recruiting, I think we had 10 users or something like that. Yeah, you can do a lot of things even if you can’t go face to face, I’ve done a lot of usability testing directly on Skype or things like that. So there’s always some cheap ways to do that.

Drew: When it comes to choosing a UI framework to work with, if that’s the route that you’re going, is that something that you would leave just to the developers or is that something that designers should get involved in too?

Stéphanie: For me, you should involve the whole team. Like the designers, the developers, maybe also architects if you have some, because how the framework is built might also influence these kind of things. Unfortunately, most of the time when they arrive on the project, the framework was already decided. No, actually it’s funny, either it’s already decided or they ask me to validate their choice of the framework, but I didn’t do any reviews or research. I have strictly no idea what’s in the project because they didn’t even show me their screens. They’re like, “Yeah, do your thing. We can use this framework.” I don’t know. Well, do we have a screen? So they ended up showing you a few screens, which was a Windows native app they wanted to migrate in the cloud. They said, “Yeah, we only need the buttons and mostly like forms and things like that.”

Stéphanie: But it’s really hard to say, “Yeah, go for this framework, we have all of the components we need.” Or like, “Don’t go if you don’t have a rough idea of what’s your content going to be, what is the navigation.” So I think you should still have kind of a global overview before choosing your frameworks unless you’re 100% sure you have all of the components. But I have a feeling that most of the time the framework choice is basically based on what technologies do developer like at the moment, do they have experience with a framework before that? We used Ant on some projects just because a few developers had experience with that and they really liked it and they were kind of efficient using Ant. And for the Material React UI it’s the same. It’s like because the developer already used it on previous projects, so they are efficient with it.

Drew: So really it’s got to be a balance between what the developers are comfortable with, what they know, what’s going to work with their technology stack and then what the requirements of the product are in terms of creating a good user interface. And you somehow need to balance the two of those to find the ideal framework for it.

Stéphanie: Yes. I have a kind of a specific requirement for some project, which is… I’m in Luxembourg, we have a lot of European institutions and things like that, so we have an extra accessibility requirement for some of those. And usually when the framework was decided, they didn’t really check about the accessibility of their framework and then they come back a few months after the beginning of the project saying, “Oh, just told us that there’s this new law and we should be accessible but we don’t know how to do that.” Like yeah, it’s a little bit too late. So for me, to choose a framework you need really to know all of the constraints at the beginning of the project and if accessibility is one of them you need to test your components and make sure that they are going to be accessible. But I am not a React or Angular developer, but I’m pretty sure that it’s super complex to turn a not accessible UI framework into something accessible. I guess it might be a little bit complex to rebuild all of the components, so things like that.

Drew: If you find yourself working on a project where that process hasn’t taken place and a UI framework has already been chosen, is there a danger that the user interface could start being influenced by the components that already exist within that framework rather than being driven by the needs of the user?

Stéphanie: It really, honestly, most of the projects I worked on, eventually you end up having a lot of trade offs, even if you really try to push. So it’s mostly about balance and discussing with the developers. So usually what I do is we do some wire frames, even quick paper wire frames, say okay, on this page we will need that and that and that component, the first thing I do is I ask the developer do we have that in our framework at the moment? What does it look like? And then we decide together, okay, this is a component that would do the job or okay this will not do the job. Do we tweak it? Like do we still keep the component but change it a little bit so that it does the job, or do we build something from scratch?

Stéphanie: And at the end of the day it will depend on the budget of course. So you ended up doing trade offs. Like I would be okay for small components that are almost never used if they’re not perfect and there’s kind of few issues. But for main navigation, main structure, things that you see all the time on the screen, for instance, this really needs to work. The user’s needs to understand how they work efficiently and yeah, it’s, as you said, finding a balance between the ideal experience you wish you would have if you didn’t have any framework and what you have at hand and the budget and also the timing. If we say, okay, for these sprints, the feature needs to be finished at the end of this sprint, and then they say, okay, but if you want your components we will never finish the feature at the end of this sprint then you start discussing, okay, do we finish this feature in the next screen, do we take more time to do it properly? And usually it really depends.

Stéphanie: The things that frustrate me the most is when I know that we use a crop fix component and they say to me like, Oh no, don’t worry. We will fix that later. And I knew that the later unfortunately might never happen. So depends on the team. But after a while you have the experience and you know, will this later arrive and or will it not? Yeah, it’s about compromises. When you are working with these kind of tools.

Drew: As a developer myself, one of the things that I like about UI frameworks is that they often come with default styling. So that means that I don’t necessarily need to have a designer maybe to help me with the look and feel of all the components. Is that something that we should be relying on in projects? Just the default styling and trusting that whoever produced the framework has done a really good job in designing those components? Or would you be styling those components yourself?

Stéphanie: I think it truly depends. The problem for instance with Material-UI is the look and feel of your a web app will be basically the configured Google products. So if you don’t actually change the font, change a few colors and kind of bring your own brand identity and do that, you’ll have a product that will just looked like any Google product, which could be a good thing because if your users are used to Google products it might help them understand it. So usually if you don’t have a designer in the team, do you have any choice? Like a lot of the different work I’ve seen, they come with custom themes so at least you can change the colors. I think you can change the fonts also pretty easily. But again, like if you change the colors and you’re not super good at design or even accessibility, maybe the colors you will use will clash, they might have contrast problems.

Stéphanie: For instance, I love orange, but it’s one of the most annoying color to work with because to have a real accessible orange, for instance, as a button with white text, it almost looks brownish. And if you want to have this really shiny orange, you need dark text on top of it to make it readable but it kind of makes your interface look like Halloween at the end of the day. Yeah, I see you laughing. But it’s true. So it’s always about these kind of compromises and say if you’re a developer and you want to use the framework as it is and you don’t have a designer, I think it’s still better than not having anything and building it from scratch and then it’s super complex to use. But the thing is, just because you have the components doesn’t mean you will build a great interface. It’s like Lego bricks. If you have the Lego bricks, okay it’s fine, but you can do a real nice spaceship or you can do something that isn’t holding together and will fall apart because you didn’t have really a plan.

Stéphanie: So design is kind of more than that. Design is about really understanding what’s going to be on the screen, how it will work. And I know some developers who actually have the capability to do that. So they are really good with usability guidelines and they understand a lot of design rules, for instance. So when it comes to choosing the components, they’re really good at that. And I know developers who have no idea what components to choose and choose the first one that does the job. But after a while it doesn’t work anymore. Like tabs for instance, we had an interface where some developers chose tabs. I think it makes sense at the beginning when you only have three items. But then there was 12 items on the screen and then you have the tabs that are three lines of tabs, and all of those are the same level one tabs, and there’s tabs within tabs. So they had the component, it looked nice because they use the framework, but it wasn’t really usable.

Stéphanie: And I had the same with like a modal windows for instance. Where they build the projects without a designer and after a while I think the client asked for more and more stuff into this modal. So they ended up with a screen with a table and when you click on add a row, you open a modal, and in this modal you have two tabs, and then in one of those tabs you even have another table and then they wanted to add an extra stuff into that, I was like, okay, maybe we can put a modal on top of a modal. And at some point the designer would reply, okay, if you have that much content in the modal, it should not be a modal window. It should be a page. So even if you have the component, you still need kind of an architect to do the plan and make sure that all of those components work well together.

Drew: So if as a designer, you’re being asked to change the styling of some components, would you just try and change all of the styling? Would you customize all of it or are there certain areas that you’d focus on?

Stéphanie: Colors I think because it’s the first thing you see, colors can actually bring you identity. If you have like a strong brand identity, at least having the colors of your product on the buttons or the icons and things like that, already helps you customize the framework. Fonts because I think it’s easy, if the framework is well-built, usually you change the whole font family in someplace and then it should kind of cascade on the rest of the site. So colors and fonts is I think two easy ways to quickly customize the framework. Icons is another nice way to bring personality, but it might be difficult because from what I’ve seen, most of the framework come with custom icons or Font Awesome or like a library already built in. So to replace those, first you need a lot of icons if you want to replace them all. So it might be a little bit complex. I have also seen frameworks that lets you choose which icon pack you want to use. like Font Awesome, Glyphicons and some of the other ones. So this is the kind of things you can quite easily customize.

Stéphanie: And then it’s about look and feel, for instance the header, usually you have different kinds of headers, footers. How do you navigate things like that. So there’s already a lot of small customization you can bring so that it doesn’t look Material-UI-ish, it more looks like your brand and then you can play around with border radius’s for instance. Whether you want completely rounded buttons, or you want square buttons or you want something in the middle like shadows also. So some small stuff that are kind of usually easy to customize because most of those frameworks have them in CSS variables. This is the kind of small things that you can customize without I think a lot of effort, except for these ripple effects. I hate that. I’m going to fight it. I kind of hope they change it eventually.

Drew: I guess things like that, that might seem obvious might seem just like a surface level effect, Do you think that would be easy to change and in this case it turns out it wasn’t easy to change? Is that just a case of speaking to your developers to find out what’s going to be easy to customize and what’s not going to be easy?

Stéphanie: Yeah, usually, especially if they’re used to work with the framework, they know what’s easy to change on it. It depends on the developer, I had discussion with one developer and I asked him if we can not have like uppercase buttons, because they are kind of a little bit hard to read, especially in the font we were using, he went into the documentation and say, I don’t know if we can customize it because I can’t see it in the API. I was like, what API? It’s like CSS class, CSS definition. You remove the uppercase from the CSS and it’s done. So he was like looking for an API to change just the font, how does the font look like. And I was like, yeah, but if there’s no API for that, I think you can change it in CSS.

Stéphanie: But then it’s complex because if you have to change this in like all of the CSS line. So it’s usually kind of a big discussion. It was the same… was like drop downs. So Material-UI, the React version we use, has some customized drop downs. So when you have a select box like form element, the select it opens these custom components and I don’t know why but we have a big problem with that on Internet Explorer. We are going to migrate to windows 10 and Edge. I’m looking forward to it, but we are still Internet Explorer 11 at the moment. And what’s happened is whenever you use or you open one of those components, it freezes the screen behind it and you have a scroll bar, so it kind of jumps around whenever you want to use one of those.

Stéphanie: And at some point we discuss with the developer, is the customizing of that worth the screen jumping around whenever users click on that. And it’s like, honestly for me, no, I prefer it not to jump and we use the select in the browser, then it will not look the same if our users have Edge and, no not Edge, IE. Or if some users are using Firefox, okay? So it will not look the same but it will be the native one and it will not make the page jump around every time someone clicks. So it’s this kind of discussion also, do we want to customize it but then it’s kind of clumsy or do we say, okay we are not going to customize it. We had the same debate with a scroll bar because we had another project we had drop-downs and they were 100 elements at some point in the drop downs. So there’s an auto complete but you can still scroll inside the drop down. And the developer said, yeah but this is looking really ugly on IE, the default scroll bar.

Stéphanie: And they investigated, they found JavaScript library that would let us have this really small little a scroll down you have on Mac and have it everywhere. Then we said, okay, is it worth investigating? We need to investigate, test it, put it everywhere, test all of the browsers. So we said we are going to do it, but only if it doesn’t damage the performance and if he doesn’t damage the rest of your experience, otherwise it’s perfectly normal that the browser element don’t look the same on any browsers. So at the end, don’t customize everything.

Drew: I guess it’s a collaborative team effort, then? Everyone needs to discuss and balance up again all the different performance factors, ease of customization and where that customization happens. So once you’ve got your UI framework in place, you’ve got all your components specified and built out and customized and styled to how you want them. I guess you need to document that in some way to maintain consistency?

Stéphanie: So at some point as a designer what we usually do, we already document them in our sketch files. So we have the working files with every single screen and everything. And in the sketch files we have really specific art boards where we put all of the different components. So that if another designer works on the project, they know that the components already exist and they can just drag and drop it in a new page and reuse it afterwards. So we have this system where we document the components also we document the use, like when do you use this component? When do you use that one? Where is this one working better? So all of the different states for instance, like inputs, we have I think 10 of those, like a focus with a placeholder, without a place holder, with content like arrows and things like that. So again, we bring consistency and then the development parts, it really depends on the kind of maturity of the communication of the team. So what we are currently building is basically a library of components and we are also building the tool around it.

Stéphanie: So my developer is currently building that and the idea is to build the component first in our kind of a sandbox, document it. Also he builds things where you can change the colors and if have a button for instance, you can change the icon, you can change the text to see if it will still work with longer text, smaller text, things like that. So we are building this sandbox and in the sandbox, you have a ‘Read me’ tab where you have documentation for how should this look, how should this component be used, when, how is it supposed to behave? Like auto complete for instance, seems to be something really, really easy, But if you start actually designing the flow of the auto complete, what happens when you put the focus in the field? Do you start auto completing or offering suggestion after one character after two, after three? If it’s after three, what happens in the meantime?

Stéphanie: So there’s a lot of different questions about that that we also document, which is really going super deep into that so that if this auto complete gets implemented on another project or gets used by another team, they know exactly how it’s supposed to work as well. So we kind of do the same. The two of us, so designers are documenting into the design tools and usually in the design tool we document the colors and shadows and gradients so that the developer don’t have to look around and try to remember exactly what the hexadecimal code for this button was and things like that. So in the end it’s kind of you have this UI framework that was super generic and you customized it, you made sure that the components you use are actually the ones that are going to help your user accomplish their goals.

Stéphanie: Everything you’ve customized is kind of starting to become your own little design system. So at the end you’re building a design system, but instead of building it from scratch, you’re basically building it using React, Material or, what was the other one? Ant or something like that. So it’s the same constraints.

Drew: Would you go back to user testing at this point after things have actually been built? Would you go back and test things with users again?

Stéphanie: We have tests, like real people testing, like regression testing and making sure that everything works. Like when you click it works, when you hover it works, stuff like that. But yes in the end, especially if we didn’t do a prototype, if we did the user testing in mockups, we want sometimes to test it again with the real users who have a feeling that everything is still working. So yeah, sometimes we go again into user testing at the end. We do that usually at the end of a few sprints where the features were implemented. So usually what happens is like we do the research, we design the feature into design tools, we do quick testing at the beginning, then it’s implemented, we do tests to make sure it works. And then again we go back to the users.

Stéphanie: And it’s also interesting because we are building a community with the users. So they’re actually quite eager to see that. The first testing was a little bit kind of a sneak peek, like, Oh, this is what it might look like. And then they are super curious about how it works and how it looks like at the end. So we go back usually in one-on-one testing for that or if we don’t have the time, we do just like panels and also we deploy it. So sometimes we do AB testing also sometimes if we don’t have time for the user testing one-on-ones, we deployed it and then we say, okay, it was deployed. If you have any feedback, please come back to us. Also if you see bugs, because sometimes we compete, the team missed a bug or something, so if we don’t have time for re testing it, we still try to find and manage to find some ways to gather feedback even after it’s deployed.

Drew: And over time, one of the things that might be a concern probably from a technical point of view is that you’ve built on top of a UI framework and then a new version of that framework comes out and things have changed. Is that a situation that you’ve experienced where a new version has come, your developers want to update but it might have implications on the design?

Stéphanie: Yeah. The thing is we have test environments, so they’re really quick and easy thing to do is like, okay, let’s put in your version in one of those secure environment and see what is broken. So from when designers most of the time when they do a new version they tell developers, is it going to break? Like is this new version something completely new and it’s not compatible with the old version? Or is this new version something that is just an announcement and you might not break that many things. So yeah, obviously sometimes when you put a new version it completely breaks, but this is again, then you have like testing stories and like technical investigation stories to decide if we are going to migrate or not. Also like from what I understand in some of the environment I worked on, they kind of encapsulated those in web components.

Stéphanie: So they’re already has kind of two different version of Angulars on some components, it was using one version on the other ones it was using the other one and from what I understood it works because then you only encapsulate what you need. So this apparently is also a solution is then you can use whatever version you want, but I’m not a developer but I feel at some point you’ll be like, okay, this component is using that version of Angular and this one, this and this maybe kind of becomes super hard to maintain. Do you know?

Drew: Yup.

Stéphanie: It does. Okay. So yeah, you make sure it still works, but I don’t have the feeling that Material-UI are like those frameworks, even bootstrap for instance, they don’t have any new version every year or something. It’s a long lifecycle and in the case of my tool, I think this tool will be here for the next year, so we have eventually to update. But if you’re building kind of a online tool, more like a B to B product. Most of the time you revise every three years or something. And usually there is a new technology. I was talking to a friend and they’re currently working on a project where they’re rebuilding and riffing on React. The first version was built three years ago with another technology. I really don’t remember the technology, but they say, okay, we are three years later, they’re already rebuilding it. And I think in like three years, they will re-rebuild it. So at some points if you’re in like in B to C products, I even wonder if you update your framework or if you are going to change the design and rebuild it anyway in a few years from scratch.

Drew: Is there anything else that we should be considering when building on a UI framework?

Stéphanie: I feel we covered a lot of things. Well, the thing is like, there’s always a way to do it quick, user research, talk to users or at least do usability testing. Make sure you don’t design or build in a silo and try to have other people at least look at what you’ve created to make sure that the components as a developer, that you used as a developer I really do wonder are going to do the job. And don’t ask the designer to put paint on top of the framework at the end of the project because it’s kind of already too late to do big infrastructure on changes. It might not work.

Drew: So at Smashing, we have books, we have conferences, and of course, we have Smashing Magazine, a website with loads of articles. We’re all about learning. So what is it that you’ve been learning lately?

Stéphanie: I’ve been taking online introduction to psychology class.

Drew: Tell us a bit about that.

Stéphanie: Last lesson was actually super interesting. We were talking about visual illusions and how they work with your brain. So it’s really super complex and there’s… Apparently not everyone agrees on the explanation of most of those illusions, but it’s interesting because I had a small psychology lesson, like I read books on cognitive sciences and things like that. So I already knew kind of the basics, but it’s interesting to see like all the different aspects of psychology. So the interesting part of this course is it’s an introduction but it explains to you kind have all the branches from say child development psychology to trauma psychology to intercultural psychology. So and then illusions and I think this week it’s actually about cognitive psychology and how to apply psychology to interfaces. So all of those really, really interesting topics. And it’s nice because it’s an online class, so I’m basically learning stuff on my couch with some tea, and yeah, that’s really, really cool.

Drew: Oh, that’s super interesting. If you, dear listener, would like to hear more from Stéphanie. You can follow her on Twitter where she’s @WalterStephanie, or find her on the web at stephaniewalter.design. Thanks for joining us today, Stéphanie. Do you have any parting words for us?

Stéphanie: Thanks for having me. It was a smashing experience.

Smashing Editorial (dm, ra, il)
Building the Web We Want

On the Microsoft Edge team, we’re committed to an open web and helping to drive innovation forward, which is why we’ve kicked off a new initiative in collaboration with Google, Mozilla, Samsung Internet, Igalia and — most importantly — the web community, called The Web We Want.

The Web We Want is an open initiative for web developers and designers (or anyone who builds things for the web) to tell browser vendors what we should focus on building or fixing. The overarching question we’re asking is this: If you had a magic wand and could change anything about the web platform, what would it be? What are problems you’ve encountered with the web that you need to hack around or what tools need to be improved or built to help you do your job better? What’s something you think you should be able to do natively but can’t? These are just a few questions to get you thinking about submissions to the initiative.

Some of the submissions we’ve had so far span from specific feature requests to broader problems with the web platform:

This is just a snapshot of the feedback we’re getting. The whole list is available for you to browse.

Why should I submit to the Web We Want? 

This is an opportunity to make your voice heard and help us determine where the future of the web platform is headed. Once you’ve submitted your problem or feature, we’ll determine if your want is something that browser vendors can tackle directly or if it’s something that needs more scoping and is suited for Web Standards discussions.

This is an opportunity for all of us to take a step back and reassess where the future of the web is heading and figure out where the gaps are that make building for the web difficult today.

How can I participate?

There are a few different ways you can participate and there are a few different components to the Web We Want. First, think about what you think browser vendors should go fix and submit your ideas at webwewant.fyi. And that could be all that you want to do, which is great! We want any and all feedback about the platform and we have folks from different browsers constantly watching what’s being submitted. 

There’s a second, optional aspect to the Web We Want, which is a great way to get involved in the web community and dip your toes in the public speaking pool. We’ve been running the Web We Want as a community-focused panel session at conferences around the world. 

If you submit and are attending one of the events we’ll be at, your submission could be picked to be presented in a 3-5 minute lightning pitch to a panel of judges during the session, like an episode of Shark Tank but for tech. The live sessions we run are a way to get feedback and opinions from industry experts like Rachel AndrewJen SimmonsMiriam Suzanne, and Marcy Sutton.

Even if you’re not attending one of the events in person, you can still participate! We want to be mindful that not everyone can attend conferences so if you your submission is selected and you indicate you’re not attending an event,you’ll have an opportunity to record your lightning talk ahead of time and we’ll include it in the live session. 

The live session culminates with the judges deliberating and deciding on the most pressing “want” pitched during the session. We also have a community voting aspect that allows the event audience to rank what they think is the most pressing thing for browser vendors (or standards bodies) to work on. Even if you’re not attending an event, you can still vote for your favorite “wants” on the website as well as by sharing them on social media. 

So far we’ve run sessions at An Event Apart DC, Smashing Conf, and View Source, and the community participation and panel discussion of wants has been fantastic. If you run a meetup or a conference and are interested in facilitating this session, reach out to Stephanie Stimac or Aaron Gustafson

The Web We Want

We’re at a point in the web platform where browser vendors and standards bodies are eager to know what it is web developers and designers need in the platform. We need to know where to invest resources. Hop over to the Web We Want and let us know what you think the web platform needs so that we can shape the future of the web together. 

The post Building the Web We Want appeared first on CSS-Tricks.

An Interview With Rémi Parmentier: A SmashingConf Austin Speaker

An Interview With Rémi Parmentier: A SmashingConf Austin Speaker

An Interview With Rémi Parmentier: A SmashingConf Austin Speaker

Rachel Andrew

2020-02-10T13:00:00+00:00 2020-02-11T00:36:57+00:00

We are so excited to be bringing SmashingConf to a new city this year. We’re bringing you SmashingConf Austin and we have a fantastic line-up of speakers.

Check out this post, where we introduce our new venue of Austin and share an interview with Miriam Suzanne, and last week’s video interview with Zach Leatherman. This time we speak to Rémi Parmentier and find out what he will share with the Austin audience.

Rémi will be talking about HTML email at SmashingConf Austin. See you there?

We’ve invited Rémi back to share more of his knowledge because he was so popular at SmashingConf Freiburg last year, and in the webinar he presented to Smashing members. You can find all of that content, including a full transcript of the webinar in the post “Become An HTML Email Geek With These Videos From Rémi Parmentier”. Also, take a look at some of Rémi’s articles on the subject.

Tickets Are On Sale Now!

If you want to join in the fun, tickets are on sale. Last year, we sold out three of our conferences well before the conference date, and popular workshops also fill up fast. Just saying!

Smashing Editorial (il)
Exciting New Tools for Designers, February 2020

Are you starting 2020 off on the right foot? How about keeping up with those resolutions to learn or try something new?

Either way, you’re in luck. This roundup is packed with new tools to help you through projects or learn new tricks to enhance your skillset. Here’s what’s new for designers this month.

Calcolor

Calcolor is a color tool that provides deeper information and meaning for every color in your palette so you can make better color choices. The tool has a contextual description for every HEX color code. You can use it to create and save digital color palettes or find better options for colors before you get too deep into the design.

Invisible Line Editor

Invisible Line Editor is a tool that helps you align text in a specific manner. You can click and drag to center, justify, or right- of left-align text. You can even download text and share. If nothing else, it is fun to play with to see how blocks of text might look in different alignments.

YourStack

YourStack, which is in public beta, is designed to help you share your favorite products with others. It’s a neat concept for reviewing tools and products. Plus, it has a nifty design that’s fun to peruse.

FlowMapp Personas Tool

FlowMapp’s Personas Tool helps you better understand your target audience by building distinct user personas. It’s deep mapping in a premium tool that can help create better design experiences.

Kinetic Slider

Kinetic Slider is a fully customizable WebGL slider based on PixiJS and Gsap. It creates an effect that lets you swipe to navigate between slides, include regular prev or next navigation, use a background or cursor displacement effect or background to titles RGB split effect.

Learn CSS Positioning

Learn CSS Positioning is an interactive article/game/tutorial to help you make the most of how CSS positioning works. Developer Ahmad Shadeed did an excellent job with this tool and presentation. It’s an amazing learning tool that’s actually fun to use.

LambdaTest

LambdaTest is an automated scheduler for screenshot testing. You can set specific time intervals and the tool will take screenshots of the desired URL. Results go to your inbox. It’s a good way to monitor websites.

Remote Stash

Remote Stash is a database of tools for contractors, freelancers, and remote workers to help increase productivity when you don’t work in an office with other people. Tools are sorted into categories to help you find what you need to do better work.

Flow Fields

Flow Fields uses a particle simulation to visualize a field of directional vectors. It uses Perlin Noise to construct a field of random (but related) forces in horizontal and vertical directions (that change over time). Go play around and watch the lines draw themselves.

BinarySearch

BinarySearch, which is still in beta, is a game to help you and your peers create rooms to practice mastering algorithms. Create problems and race to the answers. It’s a fun learning tool for sure.

Snack This

Snack This is a tool to generate text gifs in seconds that you can download and use online or on social media. Type in your words and get a screen of generated options, pick the one you want and download or export.

Shimmery Text

Shimmery Text uses SVG and GSAP to create a cool animated text element with editable controls.

Design Password

Design Password is a practical tool that’s just plain fun. It’s a tiny generator that creates passwords that are easy for designers to remember, with a description and visual cue to match.

No-Code Coffee

No-Code Coffee is a daily email newsletter packed that features a daily tool that is code-free and can help with projects. It’s free and can be a nice source of inspiration.

Monday Hero

Monday Hero is a tool that converts Sketch designs into Swift code so you don’t have to. Use it to create mobile code fast. The tool supports multiple languages, including Swift, Kotlin, Flutter, and React.

Motion

Motion is a free and simple animated SVG editor. It’s a downloadable tool that works on Mac or Windows. It comes with icons that you can edit and adjust to your liking. A premium version is also available.

Screenie

Screenie is a Mac app to manage screenshots. But the best feature is that you can search text inside screengrab images.

Greenhouse Vector Icons

Greenhouse Vector Icons is a set of flat icons in two formats and three versions with a “green” theme. If you are already starting to think about spring, this is the icon set for your projects.

All Design Conferences

All Design Conferences is just what it sounds like – a giant list of all the conference opportunities for designers in 2020. It’s based on a google sheet with a sortable, searchable design to help you plan training opportunities for the year.

Magical Rainbow Gradients

Magical Rainbow Gradients is a tutorial to help you create this fun effect. It uses CSS Houdini and React Hooks to create buttons with a rainbow effect and animation.

Chocolate Valentine

Chocolate Valentine is a fun comic-style font with fat letterforms and an almost child-like feel. It includes upper- and lower-case letters and numbers.

Dark Light

Dark Light is a handwriting style typeface with interesting letterforms and a thin structure. It includes a full character set and some alternates.

Giant

Giant is a trendy outline style typeface with an extremely high x-height. The character set is somewhat limited but could make for a fun display use.

Jet Brains Mono

Jet Brains Mono is an open source typeface designed for developers. It has an increased height for a better reading experience, weights with matching italics and is usable in 145 languages.

Red Hook

Red Hook is a double layer font with a light fill and slab outline. The design said it is inspired by the brick walls of Red Hook.

Thicker Black

Thicker Black is a super-sized extra black typeface that works for display. The free version has four variants for noncommercial use and the full version is robust with 10 weights.

Source
p img {display:inline-block; margin-right:10px;}
.alignleft {float:left;}
p.showcase {clear:both;}
body#browserfriendly p, body#podcast p, div#emailbody p{margin:0;}

Is Having an RSS Feed Just Giving Content Away for Free?

I mean, kinda.

I was just asked this question the other day so I’m answering here because blogging is cool.

The point of an RSS feed is for people to read your content elsewhere (hence the last part of the acronym, Syndication, as in, broadcasting elsewhere). Probably an RSS reader. But RSS is XML, so in a sense, it’s a limited API to your content as well, which people can use to do other programmatic things (e.g. show a list of recent posts on some other site).

If you hate the idea of people seeing your work outside of your website, then don’t have an RSS feed. It doesn’t prevent your site from being scraped (nothing really does), but it isn’t inviting people to your content the way RSS does.

But…

Don’t you want people to read your stuff? Having an RSS feed is saying, “I’m happy to meet you where you are. If you like reading stuff over there, then great, read it over there. I just like it when you read my stuff.”

It’s hard enough to get people to care about your work anyway. Being extra protective over it isn’t going to help that.

Who’s comic book are you more likely to buy? The webcomic you read and laugh at every day because they make it so easy and free to read? Or the comic that you can’t see because you have to pay for to get a peek and have to roll the dice on whether you’re going to like it or not?

What consultant are you more likely to hire? The one that shares a ton of knowledge about their skills and has firmly established themselves as a publicly verifiable expert? Or a consultant with a homepage that’s just a pricing sheet and phone number?

What blog are you more likely to trust a recommendation from? One that you subscribe to on purpose because you like their content and writers? Or some site you randomly landed on?

What web do you want to exist? One with fun interoperable possibilities? Or walled gardens?

The post Is Having an RSS Feed Just Giving Content Away for Free? appeared first on CSS-Tricks.

Guillermo’s 2019 in Review

Of all the tech-focused year-in-review posts I read, Guillermo Rauch’s is my favorite. There is a lot in there, jumping from topics like modern architectures, high-fiving specific apps, and philosophical movements.

I’ll pick one quote about the rise of “deploy previews”:

A salient feature is the transition we are seeing away from code review into deployment preview.

Code review is undeniably important (specially speedy code review), but nothing beats teams collaborating by sharing URLs to the actual sites that are being worked on and experiencing them directly.

Having a URL for every single push to every single branch (or at least for every single Pull Request¹ is huge. This isn’t just “staging.” It’s like Super Staging, and Jamstack makes it possible. Both Netlify and ZEIT do it automatically.

Not only does it help the author (and her co-workers) check out the changes on a production replica, it helps out a pile of automation tools that can run against these URLs, making for way more stable development workflows.

  1. GitHub calls them “Pull Requests” but I use GitLab just as much which calls them “Merge Requests,” so I never know which to write. “Pull/Merge Requests” is awkward at best and confusing at worst. I don’t use Bitbucket much, but they are Pull Requests there. I guess I’ll let that tip the scales and just say Pull Request from now on.

Direct Link to ArticlePermalink

The post Guillermo’s 2019 in Review appeared first on CSS-Tricks.

Custom Styling Form Inputs With Modern CSS Features

It’s entirely possible to build custom checkboxes, radio buttons, and toggle switches these days, while staying semantic and accessible. We don’t even need a single line of JavaScript or extra HTML elements! It’s actually gotten easier lately than it has been in the past. Let’s take a look.

Here’s where we’ll end up:

CodePen Embed Fallback

Things sure have gotten easier than they were!

The reason is that we can finally style the ::before and ::after pseudo-elements on the <input> tag itself. This means we can keep and style an <input> and won’t need any extra elements. Before, we had to rely on the likes of an extra <div> or <span>, to pull off a custom design.

Let’s look at the HTML

Nothing special here. We can style our inputs with just this HTML:

<!-- Checkbox -->
<input type="checkbox"> <!-- Radio -->
<input type="radio"> <!-- Switch -->
<input type="checkbox" class="switch">

That’s it for the HTML part, but of course it’s recommended to have name and id attributes, plus a matching <label> element:

<!-- Checkbox -->
<input type="checkbox" name="c1" id="c1">
<label for="c1">Checkbox</label> <!-- Radio -->
<input type="radio" name="r1" id="r1">
<label for="r1">Radio</label> <!-- Switch -->
<input type="checkbox" class="switch" name="s1" id="s1">
<label for="s1">Switch</label>

Getting into the styling 

First of all, we check for the support of appearance: none;, including it’s prefixed companions. The appearance property is key because it is designed to remove a browser’s default styling from an element. If the property isn’t supported, the styles won’t apply and default input styles will be shown. That’s perfectly fine and a good example of progressive enhancement at play.

@supports(-webkit-appearance: none) or (-moz-appearance: none) {
  input ||,
  input || {
    -webkit-appearance: none;
    -moz-appearance: none;
  }
}

As it stands today, appearance  is a working draft, but here’s what support looks like:

This browser support data is from Caniuse, which has more detail. A number indicates that browser supports the feature at that version and up.

Desktop

ChromeFirefoxIEEdgeSafari
82*74*No79*TP*

Mobile / Tablet

Android ChromeAndroid FirefoxAndroidiOS Safari
79*68*76*13.3*

Like links, we’ve gotta consider different interactive states with form elements. We’ll consider these when styling our elements:

  • :checked
  • :hover
  • :focus
  • :disabled

For example, here’s how we can style our toggle input, create the knob, and account for the :checked state:

/* The toggle container */
.switch {
  width: 38px;
  border-radius: 11px;
} /* The toggle knob */
.switch::after {
  left: 2px;
  top: 2px;
  border-radius: 50%;
  width: 15px;
  height: 15px;
  background: var(--ab, var(--border));
  transform: translateX(var(--x, 0));
} /* Change color and position when checked */
.switch:checked {
  --ab: var(--active-inner);
  --x: 17px;
} /* Drop the opacity of the toggle knob when the input is disabled */
.switch:disabled:not(:checked)::after {
  opacity: .6;
}

We are using the <input> element like a container. The knob inside of the input is created with the ::after pseudo-element. Again, no more need for extra markup!

If you crack open the styles in the demo, you’ll see that we’re defining some CSS custom properties because that’s become such a nice way to manage reusable values in a stylesheet:

@supports(-webkit-appearance: none) or (-moz-appearance: none) {
  input ||,
  input || {
    --active: #275EFE;
    --active-inner: #fff;
    --focus: 2px rgba(39, 94, 254, .25);
    --border: #BBC1E1;
    --border-hover: #275EFE;
    --background: #fff;
    --disabled: #F6F8FF;
    --disabled-inner: #E1E6F9;
  }
}

But there’s another reason we’re using custom properties — they work well for updating values based on the state of the element! We won’t go into full detail here, but here’s an example how we can use custom properties for different states.

/* Default */
input ||,
input || { --active: #275EFE; --border: #BBC1E1; border: 1px solid var(--bc, var(--border));
} /* Override defaults */
input ||:checked,
input ||:checked { --b: var(--active); --bc: var(--active);
} /* Apply another border color on hover if not checked & not disabled */
input ||:not(:checked):not(:disabled):hover,
input ||:not(:checked):not(:disabled):hover { --bc: var(--border-hover);
}

For accessibility, we ought to add a custom focus style. We are removing the default outline because it can’t be rounded like the rest of the things we’re styling. But a border-radius along with a box-shadow can make for a rounded style that works just like an outline.

input ||,
input || {
  --focus: 2px rgba(39, 94, 254, .25);
  outline: none;
  transition: box-shadow .2s;
} input ||:focus,
input ||:focus {
  box-shadow: 0 0 0 var(--focus);
}

It’s also possible to align and style the <label> element which directly follows the <input> element in the HTML:

<input type="checkbox" name="c1" id="c1">
<label for="c1">Checkbox</label>
input || + label,
input || + label {
  display: inline-block;
  vertical-align: top;
  /* Additional styling */
} input ||:disabled + label,
input ||:disabled + label {
    cursor: not-allowed;
}

Here’s that demo again:

CodePen Embed Fallback

Hopefully, you’re seeing how nice it is to create custom form styles these days. It requires less markup, thanks to pseudo-elements that are directly on form inputs. It requires less fancy style switching, thanks to custom properties. And it has pretty darn good browser support, thanks to @supports.

All in all, this is a much more pleasant developer experience than we’ve had to deal with in the past!

The post Custom Styling Form Inputs With Modern CSS Features appeared first on CSS-Tricks.

How To Create Maps With React And Leaflet

How To Create Maps With React And Leaflet

How To Create Maps With React And Leaflet

Shajia Abidi

2020-02-07T11:00:00+00:00 2020-02-08T00:37:16+00:00

Grasping information from a CSV or a JSON file isn’t only complicated, but is also tedious. Representing the same data in the form of visual aid is simpler. In this article, we’re going to represent the locations of the non-medical fire incidents to which the SF Fire Department responded on a map.

For this tutorial, we will be utilizing the following tools:

  • Leaflet
    A JavaScript library for interactive maps
  • React
    A JavaScript library for building user interfaces
  • React-Leaflet
    React components for Leaflet maps

What Is Leaflet?

At about 27k stars, Leaflet.js is one of the leading open-source JavaScript libraries for mobile-friendly interactive maps. It takes advantage of HTML5 and CSS3 on modern browsers while being accessible on older ones too. All in all, it supports all the primary desktop and mobile platforms.

Leaflet weighs about 38KB and works perfectly for basic things. For additional extensions, it can be extended with a vast amount of plugins.

A lot of newspapers, including NPR, Washington Post, Boston Globe, among others, and other organizations use Leaflet for their in-depth data projects.

The San Francisco Chronicle, for example, did a project called the California Fire tracker — an interactive map that provides information on wildfires burning across California, using Leaflet. Not only did they pinpoint the origin of the fire, but they also showed us the trajectory of it.

Since this is an introductory tutorial, we will only be marking the locations of the fire incidents and display some details about it.

Before jumping into React, let’s understand the basics of Leaflet. For this, we will create a simple example where we will be setting up a Leaflet map, working with markers, and popups.

First, let’s create index.html and app.js files in our /project folder and link the latter to our index.html file.

To start using Leaflet, we need to link Leaflet CSS and Leaflet JS in our head tags. One thing to keep in mind is that Leaflet CSS comes before Leaflet JS. That’s it for Leaflet.

There’s one more thing we need to add to our index.html file — a container that will hold our map.

<div id="mapid"></div>

Before we forget, let’s give height to our div.

#mapid { height: 1000px; }

Now comes the fun part. Whether you decide to create a new JavaScript file or continue in script tags, make sure <div id="mapid"> is added to the dom before calling L.map('mapid').

You’re probably asking “But, why?” Well, it’s because it will give you an error if you bind the map to a container that doesn’t exist just yet.

Uncaught Error: Map container not found

Creating A Map

Now, onto the fun part. To initialize the map, we pass in our div to L.map() with some options.

const myMap = L.map('mapid', { center: [37.7749, -122.4194], zoom: 13
})

Let’s go step by step to understand what just happened. We use Map class of Leaflet API to create a map on the page. We pass in two parameters to this class:

  1. We passed in a string variable representing the DOM ID
  2. An optional object literal with map options

There are many options we could pass to our class, but the main two options are the center and zoom. The center defines an initial geographic center of the map while zoom specifies an initial map zoom level. They both are undefined by default.

For the center, we passed in San Francisco’s coordinates. There are a lot of places where we can perform forward and reverse geocoding, but for basic search such as this, we can google it.

Usually, the value for zoom will depend on what you want to display. Do you want to show a city or a state? Country or a continent? Go ahead and play around with the zoom value to get a better idea. For this example, we chose 13 because it shows the entire city.

Another way of initializing the map is by using setView(). It takes the in an array of coordinates and an integer for the zoom level.

const myMap = L.map('map').setView([37.7749, -122.4194], 13);

By default, all mouse and touch interactions on the map are enabled, and it has zoom and attribution controls.

Creating A Layer

Next, we’ll add a tile layer to our map; in our case, it’s a Mapbox Streets tile layer. We can append various types of tile layers by instantiating the TileLayer class.

To create a tile layer, we need to set the URL template for the tile image, the attribution text, and the maximum zoom level of the layer. The URL template is what gives us access to the desired tile layer from the service provider. Since we are using Mapbox’s Static Tiles API, we will need to request an access token.

L.tileLayer('https://api.mapbox.com/styles/v1/{id}/tiles/{z}/{x}/{y}?access_token={accessToken}', { attribution: 'Map data © <a href="https://www.openstreetmap.org/">OpenStreetMap</a> contributors, <a href="https://creativecommons.org/licenses/by-sa/2.0/">CC-BY-SA</a>, Imagery (c) <a href="https://www.mapbox.com/">Mapbox</a>',
maxZoom: 18, id: 'mapbox/streets-v11', accessToken: 'your.mapbox.access.token' }).addTo(mymap);

At this point, if we open our index.html in a browser, we should be able to see a map of San Francisco. Let’s drop a pin on the map.

Markers And Circles

We’ve got the map and the layer, but it doesn’t point us to anything specific. To point to a particular location on the map, Leaflet provides us with markers.

To pin a location, we instantiate the marker using the Marker class, pass in the coordinates, and add it to the map. Here we are using the coordinates of Twin Peaks in the city.

const marker = L.marker([37.7544, -122.4477]).addTo(mymap);

Similarly, we can bind a circle to the map using a Circle class. We pass in a few optional options, such as radius, color, and so on. For the circle marker, we are passing in the coordinates of Point Bonita Lighthouse.

const circle = L.circle([37.8157, -122.5295], { color: 'gold', fillColor: '#f03', fillOpacity: 0.5, radius: 200
}).addTo(mymap);

Popups

This is all great, but what if we want to pass in some more information about the location. We do this using popup.

circle.bindPopup("I am pointing to Point Bonita Lighthouse"); marker.bindPopup("I am pointing to Twin Peaks");

The bindPopup method takes in a specified HTML content and appends it to the marker, so the popup appears when you click on the marker.

React-Leaflet

Now we know how to create a map, and add markers using Leaflet and vanilla JavaScript. Let’s see how we can achieve the same results with React. We aren’t going to make the same application but instead make an advanced application.

The first task for us is to get an access token from the San Francisco Open Data portal. It’s an online portal where we can find hundreds of datasets from the City and County of San Francisco. I decided to use this resource, but there are plenty of other resources out there that we can use instead.

Access API Key

  1. Make an account and sign-in to the portal.
  2. Click on the manage link towards the bottom-right.
  3. Click on Create New API Key and give it a name.
  4. Copy your Key ID and Key Secret. You’d need this to access the data.

For this, we will use React-Leaflet – react components for Leaflet maps. Let’s create a react app.

npx create-react-app react-fire-incidents
cd react-fire-incidents

Then let’s install react-leaflet, and Leaflet by running the following command in our terminal:

npm install react-leaflet leaflet

App.js

Let’s create a folder /components inside src. Inside components, let’s create a file named Map.js. This is where our Map will live. Now let’s edit App.js by removing unnecessary code and importing modules from react-leaflet axios and the newly created Map.js.

import React, { Component, Fragment } from 'react';
import axios from 'axios';
import Map from './components/Map'

In our App class, we are going to define an array in our state called incidents — when the page loads, we will push our data into this array.

class App extends Component { state = { incidents: [], } render() { return ( <div> </div> ); }
}
export default App;

Next, we will make a GET request when the component mounts. We have the app token, but we still need an endpoint. Where do we find the endpoint?

Let’s head over to the portal and click on Browse Data. In the search bar, let’s search for fire incidents. The first result that shows up is what we are looking for. Once we click on the link, we can get the URL by clicking the API button on the top-right.

We will pass in the endpoint to our GET request, and pass in a limit and our app token as parameters. The original data has thousands of records, but for the sake of keeping things simple, we have limited it to 500. We update our incidents array with our results.

Once we get the data, we update our state.

async componentDidMount() { const res = await axios.get('https://data.sfgov.org/resource/wr8u-xric.json', { params: { "$limit": 500, "$$app_token": YOUR_APP_TOKEN } }) const incidents = res.data; this.setState({incidents: incidents }); };

This is what our App.js should look like.

class App extends Component {
state = { incidents: [],
} async componentDidMount() { const res = await axios.get('https://data.sfgov.org/resource/wr8u-xric.json', { params: { "$limit": 500, "$$app_token": YOUR_APP_TOKEN } }) const incidents = res.data; this.setState({incidents: incidents });
};
render() { return (
<Map incidents={this.state.incidents}/> );
}
}
export default App;

Map.js

Since we already know how to create a Leaflet map, this part will be relatively easy. We will import Map, TileLayer, Marker, Popup components from react-leaflet.

import React, { Component } from 'react'
import { Map, TileLayer, Marker, Popup } from 'react-leaflet'

If we remember from the previous example, we need coordinates and a zoom level for initializing the map. In our Map class, we define them in our state using lat, lng and zoom variables.

export default class Map extends Component { state = { lat: 37.7749, lng: -122.4194, zoom: 13, } render() { return ( <div></div> ) }
}

Then we will check whether our array of incidents is empty. If it’s empty, we will return a message saying “Data is Loading”; otherwise, we will return a map.

In our react-leaflet’s Map component, we will pass center coordinates and a zoom level along with some styling. In our TileLayer component, we will pass attribution and URL similar to our previous example.

render() { return ( this.props.incidents ? <Map center={[this.state.lat, this.state.lng]} zoom={this.state.zoom} style={{ width: '100%', height: '900px'}} > <TileLayer attribution='&copy <a href="http://osm.org/copyright">OpenStreetMap</a> contributors' url="https://{s}.tile.openstreetmap.org/{z}/{x}/{y}.png" /> </Map> : 'Data is loading...' ) }
}

Next, we loop over our props.incident and pass in the coordinates of every incident to the Marker component. Since React warns us to pass a key to every item in an array, we will pass in a key to Marker as well.

Inside the Marker component, we pass in a Popup component. I’ve added some information about the incident inside the popup.

<Map center={[this.state.lat, this.state.lng]} zoom={this.state.zoom} style={{ width: '100%', height: '900px'}}> <TileLayer attribution='&copy <a href="http://osm.org/copyright">OpenStreetMap</a> contributors' url="https://{s}.tile.openstreetmap.org/{z}/{x}/{y}.png" /> { this.props.incidents.map(incident => { const point = [incident['point']['coordinates'][1], incident['point']['coordinates'][0]] return ( <Marker position={point} key={incident['incident_number']} > <Popup> <span>ADDRESS: {incident['address']}, {incident['city']} - {incident['zip_code']}</span> <br/> <span>BATTALION: {incident['battalion']}</span><br/> </Popup> </Marker> ) })
}
</Map>

And this is it. If we run our app, and if everything went fine, we should be able to see a map of San Francisco with 500 markers pointing us to the locations of the fire-incidents. If we click on one of those markers, a popup will appear with more information about the incident.

Wrapping Up

Even though we covered a lot, this was just the basics. Leaflet is a very powerful tool, and we can create a lot of different kinds of maps. If you want to play around, try adding another layer or a custom icon. Or maybe you would like to create an interactive Choropleth Map.

Smashing Editorial (dm, il)
Privacy Settings
We use cookies to enhance your experience while using our website. If you are using our Services via a browser you can restrict, block or remove cookies through your web browser settings. We also use content and scripts from third parties that may use tracking technologies. You can selectively provide your consent below to allow such third party embeds. For complete information about the cookies we use, data we collect and how we process them, please check our Privacy Policy
Youtube
Consent to display content from Youtube
Vimeo
Consent to display content from Vimeo
Google Maps
Consent to display content from Google