Often I come up with these great ideas that users don't like and tend to not understand easily. Templating seems second nature to programmers, after all, it's most of what we do. However, when we create a system to let our users work with a simple templating system, it's difficult for them grasp.
I told you I work at Boeing, right? There is significant brainpower at this company. It's impressive and humbling, but even still most of them completely avoid parts of the applications they use every day that have anything to do with templating.
Serial Numbers
Well, I wrote a serial number generator. It's maybe the best one that the world has ever seen. Probably the best one at Boeing.
The serial generator works on simple serial templates. A user can create their custom format for their own serial number and apply some simple variables.
{SEQ} is an incrementing sequence (1, 2, 3, etc.). {YYYY} is a four-character year. You get the idea. A sample serial number would be VEGETABLE{YYYY}-{SEQ,000}, so the first one this year would be VEGETABLE2026-001.
It's surprisingly fast and I hope it stands as the most flexible serial generator ever created in the history of the universe (lol I can say whatever I want). To be fair, it solves a lot of complex problems and will support any type of serial number anyone uses for any type of item. It does batches. It works with Excel files (why?). It does different numerical bases. It's beautifully object-oriented. It's nearly art.
Now the one and only down side: it took five years for my users to figure out how it worked. Even still, they barely use it outside of the formats I've created for them. It's used heavily, in fact it generates a large percentage of serial numbers across the company.
No, the great offense is that I asked users to create their own serial number templates, which is too much like programming to them. Users do not understand it, and have significant troubles thinking through how the templating works. I even added a live preview of the first serial numbers you will generate that updates as you type. I can hand it to them on a silver platter but they won't touch it.
The Completion Report
How do you know when an airplane is ready to deliver? I wrote an airplane completion report. It's something like that, at least. This isn't technically how airplanes work, but it makes sense in its particular use case.
So this report compares the parts it can find installed on the airplane to... you guessed it -- a template of parts that we expect should be installed. Best yet, there's a progress bar so everyone will know how close it is. They love the progress bar!
Unfortunately, in order to configure what the finished airplane will look like, someone needs to create a template of what a finished aircraft looks like. We always have this wide gap of understanding to cross before the user will realize how the contraption works. While it feels second nature to me, a seasoned programmer, it's a pole vault over crocodiles to a new user managing it.
Automatic Part Marking
I have a system where we are tracking parts in the factory. Every part has a marking, like a part number sticker or a laser-etched serial number. Every part, by its part number, has a particular set of markings. For example, the engines could all be part number ABC123. Every "ABC123" has two marks on them - two different stickers.
My part tracking app has to track these marks, so there's a database record for each. Simple relationship to the part record.
We had this great idea to let the users automatically set those mark records. Hopefully you see where this is going. Yes, this means the users would have to build a "mark template" by part, and some level of wildcards so there's a minimum mark set for every part.
And guess how well it was received? Yeah. I set it up once and no one has touched it since. Power users avoid it. Expert users kind of know what it is and never touch it. I show them how much time it saves and they ignore it.
When the mark sets get applied automatically, the users are confused. They don't get it. They just hate templates!
Saved Searches
I've got an app with a huge data table and full-featured filtering. Imagine shopping for a PC case on newegg - hundreds of cases, dozens of variables including price, brand, shape, color, size, capability, and many more.
My application, however, gets re-visited every day by our users. They tend to do the same things consistently every single day. They have their personal patterns. We can see them in our logs.
Log in.
Click to the data table.
Select the same 4 filters.
Study the screen for the next 30 minutes.
We let our users save their searches. Filters push their state into the address bar so their results are bookmarkable. The save button is conveniently located. Saved searches are even more conveniently located. Individual filters on a saved filter set can be removed in a single click. This is a simple, highly usable system.
So who saves a search template and reuses it? That's right, it's less than 10% of our users. Almost no one. Saved searches are a type of template, and users are always resistant to templating.
Templating is Difficult
It's especially difficult for our non-technical, non-computer-savvy users. It's, at least, challenging to any non-programmers.
While the results obviously point to the power and flexibility of templating within applications being able to solve some of the most complex problems we have, our users have trouble with understanding how they work, and are frequently turned off by any templating features.
My recommendation? Save your great templating ideas for the tools only programmers use.