Struggling to get going with a new feature? Start with the HTML

Tell me if this sounds familiar:

You’re asked to build a shiny new feature for your web application. You’ve got a mockup (or some rough sketch of the UI), some details about how it’s supposed to work and you’re keen to get going so…

You open your IDE.

That felt good! You’re on you way! You’ve taken the first step and now, surely, the rest will follow.

But wait a minute. What are you supposed to do next?

Design and build the database?

Build out a few backend services?

Write a test?

Implement some part of the UI?

This is a key moment, right here.

Choose wisely and you could have this feature wrapped up by the end of the day.

Head off in the ‘wrong’ direction and you could find yourself in a rabbit hole; digging ever deeper but not making any tangible progress.

Which begs the question, what is the right first step?

Realistically, there are no right or wrong answers when we’re building software.

But there are steps which bring us closer to our goals and, conversely, steps which push those goals further away.

For me, my first step in this situation is typically to start ‘sketching’ the UI, using HTML and CSS.

When you’re building for the web you’re building a User Interface.

Sure, there may be a lot going on under the surface (depending on the specific app), and the UI is a relatively thin layer on top of that logic, but it’s also the layer where most of the action happens!

It’s where the ‘rubber meets the road’, where real people attempt to achieve their aims and where our software either helps them, or gets in their way.

When we work on a feature, the main part people are really interested in (product owners, customers) is what it ‘feels’ like to use, and whether it appears to do what they need it to.

And the only way they have of assessing this is via UI.

The good news is it’s also the part that’s easiest to change, tweak and iterate, to nudge ever closer to meeting our users’ needs.

The sooner we can get something up and running in the UI the better.

It’s reassuring to have real UI to interact with, buttons that work when you click them, data that shows the current state of the system, forms to capture additional input.

This stuff is all extremely tangible, and seeing it spring to life in the browser creates a momentum-building positive feedback loop (for you, the developer).

But having something which works in the UI is also really helpful for garnering feedback.

You can take a prototype of the UI to a customer (or product owner, or boss) and ask them if it’s what they expected.

It doesn’t matter how much up-front planning and development you do, it often takes hands-on usage, and clicking real buttons to confirm whether our hunches were right.

This is where starting simple, and sketching out the UI can start you off on the right foot.

An Example

The key, when you’re building any given feature, is to start with the broader brush strokes first, before filling the details.

In practice this means starting with the ‘skeleton’ of your UI.

For example, if you’re building a Kanban board (with one or more columns containing one or more cards)…

<div>
	<div>Column A</div>
	<div>Column B</div>
</div>

It doesn’t look like much but already we’re thinking about the overall structure of this feature.

From here we can work on arranging and sizing these columns. The precise next steps depend on the CSS framework you’re using.

If we’re using something like Bootstrap we can lean on their built-in classes to arrange these columns:

<div class="container">
	<div class="row">
		<div class="col">Column A</div>
		<div class="col">Column B</div>
	</div>
</div>

Now it’s all about iteration, making small tweaks and checking how they appear in the browser.

We can add borders, and padding:

``` html
<div class="container">
	<div class="row">
		<div class="col border p-2">Column A</div>
		<div class="col border p-2">Column B</div>
	</div>
</div>

Note the use of Bootstrap’s utility classes (to set padding). Utility classes are a great way to rapidly iterate and evolve your UI whilst keeping your focus on the HTML and structure you’re creating.

Now we just keep going, fleshing out more of the details. Here we’ve added a ‘card’ to one of the columns:

<div class="container">
	<div class="row">
		<div class="col border p-2">
			<h3>Column A</h3>
			<!-- adding a card! -->
			<div class="border p-2">
				<h3>A card</h3>
				<p>Some more details about this card</p>
			</div>
		  
		</div>
		
		<div class="col border p-2">
            <h3>Column B</h3>
        </div>
	</div>
</div>

Before you know it you’ve got a solid representation of the UI for your feature, and you’re ready to populate that UI with ‘real’ data.

Not only that, but you’ve found a way “in” and eased past that ominous blank page taunting you, daring you to make progress!

Don’t be surprised if your mind runs away with itself at this point, and starts throwing up all sorts of questions about how this feature is actually going to work (and what it’s actually intended to do).

For me, that’s the clearest sign that you’re on the right track.

Web development should be fun.

Write code, hit F5, view it in the browser and bask in the glory of a job well done.

But you're not basking… Why aren't you basking?!

Cut through all the noise and build better, simpler Blazor web applications with Practical Blazor Components.

Build Better Blazor Web Apps, Faster

Next up