A 8 month project comes to life

Community resources Show & Tell
1

Hi guys,

Last week a more than 8 month project was finished (for now). It’s a site for a new orthodontic practice in The Netherlands. It has a desktop and a phone-version. And some awesome interactions to have multiple youtube embed pop-up in a modal. [not on phone] But make sure to visit it on your mobile phone as well. You can check it here:
wereldlach.webflow.io
or scan with your phone:
I’ll try to explain a bit of the process below, and trade-offs that we made. Mostly to learn about it myself, but you can read along, and if you have suggestions / tips, feel free.

TL:DR

  1. Make sure you stick to your process
  2. I would have liked the CMS functionality 8 months ago. :wink:

The Start
We agreed with the client to be responsible for content (textual and graphics), design, and execution. Put it on paper + signed it. Something I’ve done many times before, and no biggie, but this project turned out to be interesting.

This is my normal process:

  1. Make the content first
  2. Design rough mockup
  3. Get a GO on content
  4. Produce content (that’s non textual)
  5. Make first draft of website
  6. Do some tweaks
  7. Test & Done

This was the actual process:
1. Make content first
At the start I tried to start content-first. So, I deviced a structure for the client to fit in his intention that I could elaborate a bit. Basically this means: open up a Google Drive document, make some tables in which the client can write his idea/philosophy/basic texts. Split the tables in two, for a “desktop” vs “mobile” text.

2. Design Rough Mockup
We did, it’s here:

1274×4667 1.99 MB

3. Get a Go on the content
This turned to be a bit difficult. A big lesson is that I needed to fix the amount of pages I wanted to create. In other words: restrict the job to only the content I’d agreed upon in the first place. Now, the client wanted to add something he “forgot” continuously. And, flexible as I am (or hopefully was) I agreed.

Lesson: device a process that deals with “progressive insights”.

In general, the Google Doc strategy worked well, up to the point someone copied (and deleted) the whole text from the Google Doc to work in Word.

Note: there’s this thing called: revision history, so the last version was restored in 2 minutes. But the best thing about is, is that you can see changes if somehow the “track changes” functionality is switched off. You think: why do you need track changes? Because you don’t want to edit all the content all over again. So, if there’s miraculously some mistake in the content, you can “just” edit that mistake.

After that, the client had a linguist look at the text, which made the job worse. He turned out to be not that good, and messed heavily with our tone of voice in the text. Plus he made several errors with grammar, frustrating the client {and us}.

Lesson: have someone that provides excellent quality and that you trust make all the textual content

4. Produce non-textual content & 5. Make first draft of the website
As I normally do, I rent a photo studio, call up some models, and shoot the pictures. The black and white pictures turned out beautiful, and we were pleased with the result [can’t show you due to rights, but it’s almost equal to the mock-up, just different people].

We also went to the client, shot a lot of pictures from the process. Client loved the pictures of his practice. But not so much of the models. It turned out that he didn’t understand that the final pictures were going to be black-and-white, even though they were in the mock-up.

Lesson: not just involve the client on the photo shoot, have him agree (in writing) on the brief for the photo shoot.

Meanwhile we made the website, with flexible (and vh- and vw-sized) boxes. It looked stunning with our pictures. The client didn’t like some photo’s being cropped/clipped, so we tried to get them fixed in the screen. It turned out to be a drama to get that right for all the different viewports. In the end, the client liked a boxed version better.

Lesson: if you use text that differs in length across pages, and other content (such as photo’s) or your view depends on that text, make sure you use fixed heights or widths (or both).

As well, we made a phone-only version of the website. It turns out that you have to use duplicate content if you want to do that. And, if you need it to be speedy on mobile (and not load duplicate content with heavy images) make pages for mobile only as well.

Lesson: if you want a phone-only version and use images for the desktop, make a separate site and redirect the phone user like this.

6 - 7 Do some tweaks, test and done
Everyone that makes websites knows: it’s never done. So I use the “max X times iteration”-rule. This means: I make a first version, clients gives all his feedback, I incorporate the feedback and that’s it. Everything else = pay me extra. Let me be brief and say:

Lesson: Put your iteration-rules, and the accompanying “what if you need more changes” in writing and have them signed.

Around a month before the end of the project. The webflow CMS arrived in beta. I was very excited and immediately recognized that its “content editor” would have been the best feature during this process. Then, after everything is agreed upon in the Google Doc, you can transfer it into Webflow and have the client alter it afterwards as they like. And the good thing is: you can also fix the amount of characters for several fields, that’s something very, very neat for design purposes.

So, that’s my story with some lessons for process, and some about Webflow. Let me know what you think about the website, and the process if you like.

9 Likes
2

Hey leuk om nog wat Nederlanders te spotten hier!

Nice project. Site looks good.
Just curious, why did the process take so long? Misscomunnications? I understand what you are saying about content. It happens a lot. Always try to stick with your original sitemap, and add other content when your project is finished. That’s what I try. But it’s difficult sometimes :slight_smile:

And finally, it’s always important to convince the client that WE know what WE are doing. But of course that’s also difficult, a lot of clients also think they now that they are doing!

But all in all, nice project!

3

Sweet job @Diu! Really like the buttons on the startpage!

1 Like
4

Hey @Diu, love the website especially your photography and love hearing about your process. There are some great lessons in there (I’ll particularly keep in mind what you said about the linguist/translator, someone changing my copy would send me loopy!)

Cheers,
Jamie

5

Thanks for the kind words! I’m glad I’m not the only Dutchie here.

As for the length of the project; that wasn’t really something that had to do with the web design. Client needed a lot of time, as he was building his company as well. So, we could only make photographs when the building was finished, then the builders didn’t finish in time because of… well. And so on. :wink:

Thanks! What do you want to know?
On taking the photographs: Mostly I bring a small kit, never use a flashlight (unless photographing against the sun) and use natural light only. For indoor photography I use a tripod, for people I use handheld and a (big!) reflector to correct for shades combined with a very good lens. It’s not so much about the camera. Any decent camera body will do. [Although a full frame body is absolutely a pré]

On processing:
Processing is all done in Lightroom. For people I use Photoshop to add some effects, change some fine details. Or to totally give someone a new/better look. Please ask if you need to know more.

6

Good job on your 8 months project @Diu, and thanks for the case-study post, very interesting to read :smile:

1 Like
7

I have to say, I think most of the design is brilliant. This is why I was so surprised to see this when I resized the browser window:

1320×666 29.5 KB

Not only does this affect people on mobile landscape, but it affects those who do side-by-side or split screen on the 13" and 15" MacBook Pro, the 13" and 11" MacBook Air, the new MacBook, the iPad Air 2, and all similarly-sized devices including most 15" and under Windows laptops and tablets. Here is what happens on a 15" MacBook Pro when someone is browsing side-by-side:

2876×1608 289 KB

Furthermore, smaller tablets show this mode by default, as the break point is right at 768px, the width of tablets like the iPad Mini. A good example of this is the Kindle Fire with a 600x1024 resolution.

This is an incredibly common mode of browsing, and for the site to simply become unusable in a certain range, you’re creating a user experience nightmare. It shows a visual that shows someone turning a phone from landscape to portrait. So what happens when this shows up on a laptop? Are visitors going to tilt their computers? How about those who visit on a tablet who see this when they’re already in portrait mode?

8

I certainly hope not! :smiley:

@mbrannon47 Thanks for your extensive feedback! I think we run into the boundaries of Webflow at this point. I’ve had some discussions on this forum when I started the project to do a mobile-first design with custom break-points. There’s no option for that so far, thus I’ve created this image you’ve encountered.

I was not aware that is will also “hurt” most people on smaller tablets, nor half screens on the most recent laptops. So thanks so much for pointing that out. Seriously, thanks! Maybe @vincent or @thesergie can help me figure a way around it with custom media queries that override the default breakpoints for those sizes.

For now I think i’ll just add a “or use your browser in full screen” or something similar.

1 Like
9

Very nice work. Like the gray, white, yellow combo.

1 Like
10

Webflow has boundaries but here we’re rather facing responsivity limitations.

In our modern design world, we talk about user experience and responsivity, which don’t always have a reason to coexist. When that happens, don’t fight.

There are issues like background videos, who can be fixed with responsivity by duplicating elements, but there’s one thing that’s hard to fight: the fact that the landscape tablet breakpoint is… the desktop breakpoint.

When you reach such issues, and you still want to procure a real fine tuned UX, then you need a little bit more technology to make sure mobile visitors get a mobile experience.

In Webflow, at page level, you can use a script to redirect mobile users to a page especially crafted for mobile viewing.

<script>
  if( /Android|webOS|iPhone|iPad|iPod|BlackBerry|IEMobile|Opera Mini/i.test(navigator.userAgent) ) {
 window.location.replace("/mobile-version-of-page");
}
</script>

I use this on one site and it works pretty well. of course this is a nice solution for a one-pager, a lot less nice one for a 40+ pages website.

2 Likes
11

It’s such a great design, I’d just hate for the client or their visitors to think any less of the great design simply because it’s inaccessible at certain widths. Keep up the great work and keep sharing!

1 Like
12

Thanks @vincent for your insight in the breakpoints. I’ll keep the script out, since it still won’t help people viewing the website half screen on their desktop. I might device a script that overrides the breakpoints when it detects user is on desktop and not viewing full screen resolution.

Something like this:

if screen.width >= 1300, and $(window).width() < 1000px; then do-alert-thingy.