I still to this day is baffled by all the idiot geniuses who thought it was OK to have "Please enable javascript" when opening a website without JS enabled. A good chunk in many pages are just static content. You should be able to render HTML. Ashte!
Building an HTML-first site doubled our users overnight
301–310 of 605 posts
Re: Building an HTML-first site doubled our users overnight
#302Re: Building an HTML-first site doubled our users overnight
#303There is one hard wall that stops very old clients from connecting: Not supporting a new enough version of TLS. TLS 1.2 is from 2008, and TLS 1.3 is from 2018. Web browsers older than 2008 can't connect to modern websites since TLS 1.0 and 1.1 were deprecated from web servers in 2021.
I still think it's worth it to provide connections over plain HTTP for this reason. It probably doesn't apply to many people, and you shouldn't allow anything really important to happen over plain HTTP (logins, payment), but normal viewing should still be possible.
Sadly, the internet as a whole seems to disagree. Even the most useful resource on the web one could use over plain HTTP, Wikipedia, only allows connections over HTTPS. I guess it kind of made sense as part of the campaign to push the internet as a whole over to HTTPS, but anyone who's connecting to any website over normal HTTP these days is doing so because they literally can't use HTTPS.
Re: Building an HTML-first site doubled our users overnight
#304I want to work with people like this. Build the right solution to the problem with the simplest technology you can.
Same. But I never got so lucky as to find a company where this is valued.
Re: Building an HTML-first site doubled our users overnight
#305Earlier quoted context omitted.
LLM + framework you don't understand goes in ... unmaintainable garbage comes out.
Using it to understand a framework is fine.
I agree that's fine in that at least it's doesn't cause unmaintainable garbage. And might even get you up to speed quicker that reading the docs old school.
But the GP point, that you're better off finding people that already, truly understand and are familiar with the tech (ie. Astro), imo still stands.
Re: Building an HTML-first site doubled our users overnight
#306As a public policy specialist (and a tinkerer when it comes to tech), I read the article with pure joy. This is the "wonder" that happens when you build for the client instead of for yourself. It takes being truly intentional: sometimes the client (especially that kind of client) does not know what he needs or want; sometimes you as a dev simply build something with good intentions but just out of habit. Taking the t…
Everyone pays lip service to 'user experience' and 'putting the customer first', but, only with experiences such as acing customer service forms can one really claim to know what 'putting the customer first' means.
Sometimes it is just a form that you need, with the web page loading a new one after 'submit' has been clicked. Yes we can do fancy things to ajax-submit the data, but did the customer want that?
Getting to the form in its 'final form' takes work, particularly if asking the customer for more information, such as proof of purchase or important documents. Do you just start the conversation with a 'contact us' box to have customer service ask for the bits they need later, or do you ask the customer for all information up front, reducing the need for back and fore?
You need to actively test what your customers will do, with metrics such as time filling in the form and how big the ticket queue is.
There can also be internal problems that prevent getting the form right. For example, if there is some manager in charge of customer service that is an empire builder, with a vast team. If your form decimates the team because everyone is efficient and able to go home at the end of the day with an empty queue, then you have undermined the empire builder, so he will want you gone!
There are some huge benefits to getting customer service right. You can brazenly have phone numbers, email addresses and even physical addresses, all published on the website. If the forms work then the phone never rings, the inbox is empty. And nobody can accuse the company of hiding behind a wall of corporate website small print.
The word of mouth aspect is also not to be overlooked. You can harvest reviews from happy customers that should have been unhappy under the old system. If you fix their problem in an hour, or get a replacement product to them the next day, then they will write you a rave review, with that being great for the customer because they explain better than you can how dedicated your customer service team is.
I use the word customer lightly here, there is the term 'service user' that is used in the public/third sectors, but that doesn't sound good in front of the 'service user', probably because they have an actual name.
Getting to the form 'in the final form' means quite a few small changes that can be easily reverted and monitored. It could be just making an input box only show capital letters, or show a numeric rather than standard keyboard.
Ideally, a submitted form does something when completed to place the ball in either the customer service court or that of the customer. If the customer need to provide some information before anyone need look at the ticket, the form needs to send out that email, then park the ticket awaiting whatever the customer does next. There should be no need for someone on the team to do that step.
I know AI does everything awesomely under all circumstances, but the 3-6 month journey needed to deeply understand the customer, the product and the team is something that needs a human, simply because you are dealing with humans and their emotions.
What has proven to be a huge bonus is CSS grid styling. Inputs and labels can be written without the div and span cruft, with everything lining up nicely with a few align 'center' CSS things.
What a fun time to be doing forms that actually work!
Re: Building an HTML-first site doubled our users overnight
#307As a non-web dev, I have a question about this part: > There was a sad coda; as is the way of contract work, I moved on. I explained what I had built to my replacement, that it always worked even without javascript. He was appalled and said, “but that’s a lot more work for us.” Why is it more work? The approach described in the article seems honestly reasonably simple: just write the standard components for the form,…
Starting a few years ago, I realized some junior and medior engineers never once considered the possibility of building a website (app, experience, etc.) in anything other than a heavy SPA framework. But they're not stupid people! If you directly asked "Can you build a website without React?" they know the answer is obviously "Yes." However, if you asked them to build a new website, they would unthinkingly start a ne…
Kinda sorta analogous to the cloud engineers who can standup complex monstrosities in AWS-land, but don’t know the first thing about how to troubleshoot say a connectivity or simple problem where they have to ssh to an ec2 box and do the needful
Re: Building an HTML-first site doubled our users overnight
#308This isn't "We replaced a React app with an HTML form and performance improved." It's "We replaced a bad web page with a good web page and performance improved." Attributing this to the technology driving the browser experience is silly. You can make a brilliant user experience with React. You can make a terrible website with plain HTML. The improvement comes from the change design, not tech.
The standard answer to that is that some technologies make one harder than the other. That's kind of true from first principles, but it requires making the case that e.g. React is actually harder to make good than a plain HTML page. Fun thing, TFA describes a kind of multi-page wizard style form that I haven't seen a lot anymore in the last decade or so. But when I did see it, it's always some dogshit enterprise syst…
Is it slow though? Like in practice? This demo [1] using Datastar (a streaming HTML framework) every action including scrolling roundtrips to the server. Even the checkboxes changing colour is a roundtrip.
Re: Building an HTML-first site doubled our users overnight
#309As a non-web dev, I have a question about this part: > There was a sad coda; as is the way of contract work, I moved on. I explained what I had built to my replacement, that it always worked even without javascript. He was appalled and said, “but that’s a lot more work for us.” Why is it more work? The approach described in the article seems honestly reasonably simple: just write the standard components for the form,…
This was the jQuery way. It was called Graceful Degradation. The entire approach went out of style with the advent of single page apps, React, Angular, VueJS, etc.
That's generous. I always heard people espouse that ideal, but I rarely saw them actually do it. And I never saw it at work.
There were always certain UX requirements that required JS, and that meant the company wasn't interested in testing to make sure it worked without JS. None of their customers were going to use it that way.
Angular, React, etc helped force it further, but they didn't cause it.
Re: Building an HTML-first site doubled our users overnight
#310Old people. They exist. Not even that old. 60 year people can't user your fancy site because then don't have an internal model of how a computer works. You know that when pressing a button a hidden engine runs in the backend (or something runs in the backend). You expect an answer and if the expectation do not match the result, the model in your mind creates an hypothesis about what maybe happened and iterate from th…
This describes all non-technical users, not just "old people."