Get Rid of the Submit Button

I am starting a movement against the Submit Button. Perhaps you've seen it. It's the annoying button at the end of every web page you visit that requires a button-click before anything happens. It's also in every window that comes up in your operating system. Sometimes it says Submit or Enter or Go or Yeah! They slow users down, and honestly, with computing prowess nowadays, They are not necessary.

And I'm not talking about Confirmation buttons. Confirmation is different. That's an event we want the end-user to participate in. Enter information, confirm, submit. But the typical submit button is simply requiring the user to click another button after they are done with whatever it is they were doing in the first place, to make life easier for the developers of the site. This button is now irrelevant with today's technology.

How do you get rid of it? Use AJAX or a similar Rich Internet Application technology (i.e. Silverlight or Adobe Flex). Instead of triggering events on a button click, they should be triggered on the completion of a particular form element or a key stroke. This is not hard to do with today's programming languages. It may require a couple more lines of code to handle the idiosyncrasies, but at the end of the day, the extra work for the developer will pay dividends over the work required by the users.

Please, do a friend a favor and remove the submit button, be Green and Save a Click.

Use the comments below if you think I am wrong, I will be happy to respond.

Use the Power of the Internet to Scale Your Portal (or any web app)

Did you know that regardless of your infrastructure, you have the largest, most powerful performance enhancing platform in the world at your disposal? This platform is vast, infinitely scalable and most of all, it's free. What is it and how do I sign up? It's the internet itself! Let me give you an example of how to take advantage of this.

My company does a lot of Portal implementations and customization. Portals are great for users because they consolidate content and services from across an enterprise and present the information in a unified, consistent user interface. iGoogle is a great example. Portals are also a pain in the butt for developers, mainly because of the dozens of integration points that often make up a personalized portal page. The top right corner may be pulling weather information, underneath it a customized stock portfolio, under that company announcements, info from your HR profile, personalized lists of your client accounts, etc. Each of these blocks of information (or portlets) make individual calls to retrieve this context-specific information. So one call to your portal page, often turns into dozens of portlet requests to your data center. That load adds up quickly and makes performance and scaling a challenge.

Regardless if you're running a portal or not, the key to good performance (and ultimately scaling) for any web site is caching. A great rule of thumb is, the closer the content is cached to the end user, the faster it 's delivered. If the content is cached in their browser (i.e. an image) bingo, it's there. If you have to go back to the webserver to retrieve a pre-generated HTML page, it's a bit slower. Have to go back to the app server (behind the webserver) to run some logic to create the HTML page, slower. Have to go back to the database to pull some data the app server needs, slower still. Have to go to some external ERP or a content provider, slower, slower, slower.

There are several persistent and in-memory caching options out there that you can use to avoid multiple trips to external systems. But what about avoiding trips to your data center all together? This is where the internet comes in.

Every request (from a user) and response (from a server) sent through the internet hops across several intermediary servers between your data center and the user's web browser. At each of these hops, the intermediaries check what are called "response headers" to see how long they can cache the data that has been made from previous requests. That means when person "A" requests weather for Chicago, if your system is architected right, the next person will get the same information without having to go to your data center to get it.

The key to enabling this caching is two fold. The first is customizing your URI (i.e. URL) to be specific to how you want data to be cached. The second is using the response headers' cache-control directive to determine how long that URL's data should be cached (i.e. one hour, one day, one week, etc.).

For example, if your page's or portlet's URI is "http://www.mycompany.com/weather" and the responsibility is on your webserver to figure out where that user is from and serve up weather appropriately, caching on intermediary servers is not going to do anything but cause problems. But if your URI is "http://www.mycompany.com/weather/Chicago" now you have a specific request that can be cached for up to 12 hours. Any subsequent requests by Chicago-based users isn't going to hit your data center and will be served up by intermediary servers. This decreases load on your servers, increases performance and quickly adds up to huge hardware savings.

The same trick can be applied to any relatively static information. Use response headers to cache information that isn't going to change that often. And if the information is personalized, figure out how to bake that personalization/segmentation into your URL so the context-specific data can still be cached by intermediaries. This may not apply to exclusive information (i.e. account balances) but if you utilize AJAX and REST in your page creation, that can be a small hit to your data center, while the rest of the page is rendered from cached information on intermediary servers.

So use the power of the internet to your advantage to scale effortlessly. If you think about most page's makeup there is a very small part that is truly user-specific. The rest of it can be served up by the internet at large, and that's a great way to scale without spending a dime!

This blog was also picked up by CIO.com

Rubbin's Racin - Infrastructure and Apps Need To Work Together to Win

Did you ever see that (terribly) awesome movie, "Days of Thunder"? If not, watch it, it's probably on TBS right now, or just read this. . .

From my experience, Infrastructure in IT is about building a car , and Apps is about driving that car. One can't succeed without the other. Success is determined by the fans of the car and the driver. If the car wins, awesome. If the car loses, who's fault is it, the car or the driver? The fans don't care.

I like to build race cars (I am a young Harry Hogge). I admittedly grew up as a Cole Trickle, but now when it comes to building scalable computer systems I think about the infrastructure first: The network, the memory, the CPUs, the storage and the car's internal computer (you know, the middleware, the stuff that makes sure that the driver can 'safely' use all of that metal to it's fullest potential).

So who are the cars' customers? Application developers. They are the drivers. Cars are built based on the developers' requirements. But often the developers are constrained by the car provided to them. They can only turn the corner (or process transactions) as fast as the middleware (computer) will let them. They can only go as long as the gas tack (storage) is available. When they launch the car they find their racing lines in the context of what the car can handle. But whatever path they choose, it's the car's responsibility to ensure the path scales, that it's consistently available for every loop around the track.

The unfortunate reality is that most organizations put a wall up between the car (infrastructure) guys and the drivers. They point fingers at each other when something goes wrong, performs poorly or doesn't scale. You hear things like "Cole Trickle doesn't know how to drive the car the way it was meant to be driven" or "Harry Hogge's car is a piece of garbage". Or in IT terms. . . "Cole's code is waaaay too memory intensive and needs to be optimized" or "Harry's RAM allocation for our application is ridiculously low and needs to be increased."

The reality is. . .the fans don't care. They don't care if you're a mechanic or a driver, if you're on the infrastructure team or the apps team. The only thing the fans care about is if you're winning or losing. And you can't win with a bad car and a good driver or a good car and a bad driver. You need them both. One can't win without the other. And the better they work together, the happier the fans will be.

-J

Good 2 minute video on Why Google Wave

Thanks to Epipheo Studios, a solid explanation on why Google Wave will rock. . .