Ok, this won’t win me any points if some random web app developer happens across my page, but I have a request for anyone who’ll listen.
Please, for the love of God, consider the actual user of your application.
Let me explain where this comes from. I work on the development of a web app, not in the technical sense (I’m not working in the backed), but I am using an admin-type web interface to modify and enhance the UI that our customers will use. So, in essence, I’m the middle man. I consume what our solution provider makes, use the product to create another product, and then maintain that second product. Confused? It’s a standard scenario I’m having trouble verbalizing at the moment (Christmas is close and I want out of here; give me a break).
This is my dilemma, issue, beef, if you will. One of my tasks is to implement user assistance. I won’t get into the idiotic implementation our solution provider has “provided”, but suffice it to say, they need to read this post as well. We have gone with hosting static files on the same server as the web app, linking to those files from the UI of the application, and then doing whatever we need to do in our own “environment”, so to speak. Yes, it’s a hack, but it’ll work for our purposes and minimizes the politicking that would be required to use, say, ASP. I digress…
My plea begins here. Adding a link to our static pages is fairly simple, unless you want to do anything except add a value for “href”. Why? Because the Active X control that has been implemented allows only for input of a protocol and an address. Because lots of people are linking to Gopher these days. (Seriously, that’s an option in the pull-down menu.)
This is a dead easy thing to implement. Allow me as a middle man user to add links to whatever I want however I want. I can’t say how much the system cost the organization, but adding fifty bucks to the cost of the license to implement an Active X control that allows me to specify a value for “target”.
I know that right now, someone is saying, “just edit the code, dummy.” Yeah, there’s another shortcoming. While you can edit the code directly, sometimes code changes take. Sometimes they don’t. No one set down why code would be reverted, or a way to change something and set an ignore switch somewhere. Even our developers went, “Humph, isn’t that interesting?” Not very helpful.
After I rolled my eyes for the 7th time this morning, it dawned on me that I’m on the receiving end of a more fundamental problem. It’s not that the tool couldn’t accommodate these enhancements, it’s that the solution provider didn’t think anyone would use their product any other way than how they imagined it to be used. Ok, that was a mouthful, so I’ll just say it bluntly.
The original developer was shortsighted. They envisioned a single scenario of implementation and use, for both the middle user and the end user. It never occurred to them, or was completely ignored by them, that legitimate uses outside of their development efforts should be accommodated. Every crappy HTML editor in the world allows you to set values for the “a” tag. Not theirs. Why? It would’ve cost them something, and they weren’t willing to spend the resources.
Who am I to tell them how run their business? Their customer. While it may be a PITA for me to work with, I have to work with it because I have to provide a solution. The ultimate sufferer is going to be my end user, my customer, because I have to spend ridiculous amounts of time coding the simplest things, which leaves less time for me to actually assist the user. To me, that’s a bad tradeoff.
So, my plea is this, web app developers (or, really, solution developers): Think about the actual end user. Make your solution fit what they will need. If your customers (people like me) are going to use you app to build other apps, I need to provide things like documentation, user assistance, UI enhancements, and god knows what else. Making it simpler for middle-level developers to use your apps only improves your products.
You Know What Part 
