HTML5 and the Future of the Universe

Web site people are always catching up. You get involved in an extended project and by the time you're done, they've changed the rules again and it's time to learn a new technology. I used to think this was a problem. Now I see it as a responsibility to manage the information of an ever expanding set of hardware devices that are becoming digital.

As these digital devices become of age, they mature into a web access point because of the value it adds to the device. Some devices like tablets are born with the ability to talk to the web at birth. Others, like DVD players, had to wait until they grew up.

HTML5 and CSS3 are expanding to fill the needs of the digital appetites of these new devices. As we innovate to market test a device at every screen size possible from phone to tablet to TV, the older development technologies will continually be updated until they break. So far, HTML and CSS are holding their own. CSS not so much. Even the old dog, JavaScript, is doing well but has some sturdy jQuery and CoffeeScript crutches.

The raft of programming languages not originally focused on the web that try to manage that environment push the simple text retrieval process to be more app like. In their desire to improve the unique asynchronous request-response communication model, they, in my mind, will eventually destroy it. Face it, it's slow. You can do faster communication with AJAX which is why you see Google using so much of it on their web apps. It's why jQuery Mobile designed their GUI library for speed with AJAX so much that it's the primary communication model that tolerates the web request model.

Now a newer model of finer grained I/O control in JavaScript is starting to appear called the WebSocket API. Did you not see this coming? It's not the end until each language has a way to use a simple library of functions/methods to talk to any device of your choice.

Languages are shifting little in popularity. A recent TIOBE trend announcement showing that the iOS platform language of choice, Objective-C, has been the faster gainer over the last two years to take the #3 spot on the chart, is the only major change. With Java trending downward and losing the lead to C, a venerable stalwart, I'm not seeing where anybody is picking up the slack. C# is on a slow trend upwards but not that much. Even php is losing ground.

My guess is that JavaScript is picking up the slack from reading language popularity articles. You can run a survey of projects on StackExchange and Github and find out that JavaScript has the top ranking there. Hacker News put JavaScript in the top three as well with Python and Ruby taking the top spots. Even job rankings on Dice.com show JavaScript in the top three to get a better sense of real world usage. Book sales from O'Reilly put JavaScript at #2 showing a mix of business and hobby use.

The next step for JavaScript would be to revive the server side version of the language and make it as available as php is for Apache. Then the major languages would write APIs to talk to JavaScript and we would have a programming interface for the web. Oh, yeah, and somebody do something in JavaScript to make CSS easier to work with. LESS is a good start.

So, if you are a web person, the future of the web looks like it centers on web application development and JavaScript is taking center stage. APIs will be promulgating and JavaScript/jQuery/minor language support plug-ins will be promoted. One of the APIs that is next on my bucket list is YQL. I think with the first book out on YQL in a few months from O'Reilly, we'll see an interest in mining the data of the web from JavaScript languages.

Excuse me now, I have to get back to the future and read about what's coming so when I start working again I won't be too far behind.



By: Doug Hoff

The Web’s 4 Hats & an HTML5 Overview - Part II

Designer

The designer in me wants to have my great user interface so well integrated into the data and processes that you don't notice. And I want it to be beautiful. That hat wasn't the one the standards committees were wearing when they proposed the gradients and transforms. Misguided blink spans and easy marquees have been put to death as many times as Freddie and Jason but keep coming back for more. Now we have them again, only this time a little more well dressed. I really don't even like the drop shadows but some of these will look much better to the high-res tablet crowd.

I am happy with SVG support and the graphics we can do, but where is my visual SVG graphics designer integrated with HTML and CSS? Android was the last to jump on the SVG graphics bus and most of the rest of the cheesy effects have partial support so I know I will be trying out Inkscape and SVG Edit when I need.  Or I'll just sit back and let the widgets take over for me like the SVG based Chart control in Visual Studio and jQuery plugins.

I find the most pleasure with web fonts, especially Google's public accessible fonts and having Web Squirrel give me everything I need to do it on my server. I can talk to the device to get info I need to deliver a pleasing layout with the @media queries. And when I need that old-timey newspaper look, there's multi-columns, but I fear it's a retro feature that will be better left alone due to the complexity it creates for the layout.

Surprisingly, I think the designer ended up with some of the best improvements. Colors are better defined both with more names and flexible opacity. The video and audio elements will have to wait for the patents to become less profitable while we find a common standard to work with. The dominance of the iPad will force me to encode a different way but I don't like it.

Businessman

If you want to know who is going to win the HTML5 battle, you just have to follow the money. And the hat in charge of the money is the businessman. This hat is the hardest to wear since it requires you to not think technically and focus on the customer. Does the customer really want what we think is geeky cool warez? Probably not.

I liked the idea of doing a survey of the currently used names for divs and classes in the wild in order to understand how people used HTML. But what were we supposed to do with that? Did I really want a better element because I was really happy with just calling my div a wrapper in the id and not a section. You want me to recode it? When?

What helps me make money? Coding faster. Reusing other people's code. If all you do is rename things, then it's going to get in my way. Now if you make it easier to find elements in CSS by adding better selectors, I'm not going to complain but it is looking more and more like a grep or regex language these days.

I can reuse other people's code if they've marked up what I want to use and now we're back to microformats because what I want is not generic text groupings that are or aren't related. What I want are finer granulation on the most common business entities which is exactly what the microformats do.

Other types of useful abstraction that will be faster or give me critical information are the new communcations APIs like Web Workers or Web Sockets and the ability to let me work offline with session or local storage when paired with the page caching. Geolocation is just a one-trick pony but had to happen when you start moving yourself around instead of sitting at the same IP day after day. And the database storage on the client will improve the user experience for offline as well.

Conclusion

People want a desktop application experience on the web and want it whenever they want it there. People have to have it easy and that means the developers as well as the users. So will I use the semantic markup? Probably. It will help me as a programmer. Will I use the <canvas> and other graphic elements? Probably not. I like SVG and JavaScript generated graphics as long as I don't have to write it. I can use Adobe Edge or other visual programs for that. Will I use the features that aren't well supported like drag & drop and datepickers where I can use jQuery and jQuery mobile to get standardization now? Obviously not.

The 2-D and 3-D graphics are incredible and not in my realm as a web developer but if you are a game developer that wants to leverage the e-commerce platforms of the future like the Apple App Store, Android Marketplace or possibly the Amazon juggernaut commerce system, then you must develop using <canvas> because it's the fastest and standardized.


As to why standards groups like the W3C and WHATWG don't move too fast, it's because you have four different groups of people all lobbying for their view. The DBA had the upper hand in the last version and now the designer and the engineer seem to be dominating. But like a real business, it's the dialog that is important to crafting a best solution for the whole. Let one company or one hat take over and it would be an impending fail.

The businessman is going to take you to that application experience that you so want. And he will charge you for it and pay you to develop great apps for it. The standards committees don't think like businessmen so you'll need to see what people are really using, really need, and get paid for. My best bet is to watch Google for how they use search data and to watch Amazon for how they will use their e-commerce platform. Of course, you'll also be watching Apple and Facebook as app delivery leaders. Then code for it and enjoy.

- Doug Hoff, Business IT Expert; MCT, SCJP, ITILv3, COBIT LinkIn with Doug

The Web’s 4 Hats & an HTML5 Overview - Part I

I recently returned from speaking at a conference in Kentucky where I ended up putting on four hats and seeing HTML5 and the future of mobile computing differently each time. I was struggling with trying to figure out why standards committees take so long to come to an agreement. After all, the vision of the web is clear, right?

Why did we get off the XHTML superhighway and jump on the scenic route where we ignore the bumps and potholes of bad syntax and limited metadata? What kind of folks are driving the bus right now and are they really going the right direction? Should we stay on the bus while we head into Mobileville? I've decided that the questions you pose are at least if not more important than the answers you think are right. Because that tells you what your vision is and if you've followed a little of this blog, you know that strategic vision is important.

The four hats are:

• The Engineer - who likes all of the functionality logically thought out
• The DBA - who likes the the data well defined and stored
• The Designer - who likes to deliver an emotional message to the customer
• The Businessman - who makes sure the customer is happy and they make a profit

Those four hats have led me to not watch the standards groups as much as watch Google and Amazon for what to use in the future that people want. The real vision of the web is to make money by giving computer users what they want. Waiting for standards groups won't get you there. After all, the current prediction is that CSS3 will be completely standardized by 2022.  Here's a rundown of the first two hats:

Engineer

As a software engineer and instructor of many students who become programmers, I know that the web has become populated with these folks that want to turn it into an application environment. That way they can program for it and make it do their will. The back end servers are full of Java, C#, and php and that same force is heading to the browser with JavaScript.

I see the HTML world being altered so that these variable manipulators can have better code and read each other's functions easier. The push in HTML5 towards meaningful naming of the loosely typed datatypes that were divs and spans is going to give programmers a better handle on what it is they are talking to. The code will become less dependent on ids and more dependent on setting up the HTML with the proper element names like <mark>, <time>, <progress>, <meter>, <details> and some of the more argued over names like <style scoped>.

I can see where the types of activities previously handled by JavaScript are being pushed into HTML. This reduces the language down to one, slightly more complex, language. Do we want a merger here of interests? Is the MVC principle being corrupted and should we really mix our text markup with programatic data validation in the same code module? The data and its validation are View Model pieces that are tightly coupled and should be handled together in my mind.

So the future lies with the ultimate merger of HTML and JavaScript and we'll have a Razor style view engine in all browsers eventually. My opinion is not to follow the same syntax and find a better way to merge the two. But the merger will eventually come. Simplified syntax for CSS3 and JavaScript have started to reinvent these stuffy languages and if jQuery can simplify CSS with a replacement like EZ-CSS, sass, or less, then we're on our way. I'm hoping it's not like node.js and stylus, but I need to try those more.

DBA

I also love to understand data and its meaningful use. Having the right field name and the right multiplicity gives me a warm glow. But I also know that too much data analysis can torture those poor programming souls who have to recombine the data for the page they work on.

Here we're not talking about the fields where programmers hand over their data after the output is available but where the data can be semantically meaningful as text. These are the domain entities and at a high level they are represented by <header>, <nav>, <footer>, <section>, <aside> and <article>.

My biggest hurdle here is knowing that the data already comes from a semantically proper framework called the database. If all the work has been done there, then who benefits by rethinking the meaningful structure one more time for the web? The only answer is that the DBA traditionally send the data to the programmers who use that "data markup" for their benefit. The field names become bundled together and as I put back on my Engineer hat, I am happy to create complex View Model types for my View, the web page.

But it's reinventing the wheel when there's a database and it's better for team coding experiences to have more readable code. But wait, is there a web service that might be looking for my article elements? Not yet in the HTML5 way. If you are looking for a current semantic framework of entities, you have to look no further than Google's recommendations. The microformats they recommend carry much more weight for reasons to mark up with them than just a standards board. People are using the schemas for reviews, events, organizations, places, restaurants, recipes, etc. without even knowing about it but you are losing out on having Google process your data and provide search results with it if you don't.

The XHTML push that we unceremoniously dumped was a DBA's dream for a perfect interface language between data source and data consumer. The problem was that it's not a homogenous set of data. Our web DBA's don't work under the same domain and the complexity made it uncomfortable to work with so many needs and choices that we found had already been solved with another data model. Or two (relational and objects). We didn't need a third (XML).

To be continued...

- Doug Hoff, Business IT Expert; MCT, SCJP, ITILv3, COBIT LinkIn with Doug

Designing Automated Processes for Business: Applying ITIL to coding (Part III)

Process enablers

The enablers of a process are combined assets of the resources and the capabilities of the business. These are the raw materials and the smarts of the folks that are getting the job done. On the computer programming side are the programming language capabilities and the hardware and software's raw power to get a calculation performed or a sequence of code executed. We measure performance here in FLOPS (floating point operations per second) and computers are moving through the petaflop (1,000,000,000,000,000) ranges now. Business processes depend on the business assets just like code depends on the infrastructure it runs on. Unfortunately, business is both enabled and limited by humans and computers both enable and constrain business.

Processes are not much different whether you do them manually or if you have a robot do them for you. The programmer acts as a plumber in a business process. They know the mechanics and apply the right torque to the right nuts and bolts to hold the system together. The business analyst is going to map out the system so that it works for the business the best. Sometimes the programmer finds out that they have to plan it out and does the best they can. But you should always get involved at the first to direct the code so that is best represents the business. That's always the best strategy to take for any new project.

- Doug Hoff, Business IT Expert; MCT, SCJP, ITILv3, COBIT LinkIn with Doug

Designing Automated Processes for Business: Applying ITIL to coding (Part II)

Process control

Processes should also be well defined in understandable text just like we always do to our fellow programmers when recommending comments in their code. And just like the norm in programming, most documentation happens after the fact because people don't have enough time to document the program until it has stopped changing at the end of the development cycle.

Process owners are the people who understand the process and can help educate others on how to use the process. I have to help naive ITIL students who tend to think that process owners are not in charge of implementing the process. This always gets me on my soapbox. An implementation of a process, e.g. an ITIL key process, is not going to happen because you read the book. It must be digested, customized by deleting the right parts, and supplemented with all of the current business structure in order to be understood. Then the process activities are noted and people check them off as they need to when they need to encouraged by success and trimmed down by reality. In programming, it would be the project sponsor who got the ball rolling for the new software and would own the software when complete. They also get new funding when the project is a success and get project funding reductions when the process is too cumbersome.

How and when the process is used is a matter of policy and the ways that you can use these process steps have limits. Just like a computer program, the steps can be run for certain types of tasks and shouldn't be run for others. You don't close the books of an accounting process except for once a month. You don't ship more inventory than you have in stock. Process objectives are probably determined by what planted the seed in the ground for using this process in the first place. In a software project, the business objectives drive the funding and usually can be found in a business case document or a sponsor's mind.

I was reminded of the input and output nature of a process when looking at the method declaration and saw that it defined a general form of a resource just like all the other types of resources. But until functional programming came along to supplement object oriented programming, we never had a way to send the process information from one place to another internally even though the values of any data could be sent to and fro. The methods represent values but only in an abstract way. In a distributed world, the process is represented by remote procedure call frameworks like CORBA, web services and other forms of proxied calls. Data was distributed through XML, EDI, and all sorts of more simple data models.

Software testing is a way of thinking about your code from the norm or from the original business requirements. This validation is a quality aspect of coding. Test driven design drives home the point that the test is a way of thinking about how your code should be called and used before the implementation is written. ITIL states that "Even before starting, it is important to think about what the process outcomes should look like." (Service Design, p. 44) We also work with requirements in a hierarchical way so that the lower level requirements of the code can roll up to the next level of activity and eventually be mapped to the business goals that drove the project. Then when the system is complete, we have a measurable way to compare what was originally planned and implement improvements if necessary.


- Doug Hoff, Business IT Expert; MCT, SCJP, ITILv3, COBIT LinkIn with Doug

Designing Automated Processes for Business: Applying ITIL to coding (Part I)

Programmers are guys who write business processes into stone with a kind of invisible ink. The better you tell them what your processes are, the better business results you will have. They are not people who model the world into code because they have no clue how the model works. They will come up with a well-engineered version of the reality they are coding if left alone and that will have to be the way you run your business if you don't tell them how the business works. It will likely more resemble a massive robot rather than a enabling friend.

I've recently completed a series of classes that involved business analysis, ITIL, and programming. Sometimes, I think about the subjects in depth and explore the details. Sometimes, I like to bring all the thoughts in alignment if possible and see the relationships. This time I got a good set of cross linked ideas that help look at what processes are from the business activity on down to the automated processes of a OO program.

As a programmer instructor, I talk about the recognition and the reuse of a set of statements that become a method (or function or procedure). As a business instructor, I teach the same thing concerning recognizing a process that you find useful and promoting the use of it into a larger group of people. As your process maturity level grows, the process grows from your own use, to people using it around you, to even more people until it's a company-wide standard.

Those same maturity steps are used to develop large scale architectures that provide guidance to the necessary design of the infrastructure that has implemented it. In fact, it's the principles of good design that have produced an architecture that works for the business. Sometimes business doesn't know which architecture to choose or isn't able to strategically point the direction and then takes the low road of design by infrastructure. This is the choice to buy instead of build and results are good as long as you stay compatible with the other components that are added on. Again what you end up with is a well-engineered solution without regard to your specific business needs.

The business processes that exist within a coordinated automated system or an infrastructure are essentially the programs that are being executed. They have been structured so that they achieve a specific objective. They take inputs and turn them into outputs. They have a specific trigger. They are layered into automated roles and responsibilities to work well when they have to be maintained. Just like it was an employee, you can fire an architecture layer and hire another version of that layer that fits the bill when managing a cohesive set of responsibilities in a business.

As far as I know there's not as much business writing going on for how to design a job role with few dependencies to other job roles but one of the common axioms of being promoted in business is that you must make yourself replaceable or else you'll never get out of your job. That's the same kind of thinking as when programmers say they must make their programming units reusable or maintenance will become more of a headache.

Process

If processes equal computer programs then they must have similar features. They can be broken down into smaller processes. They are either ongoing processes or processes that have well defined starts and stops. Processes can update policies, standards, guidelines, activities, other processes, procedures and work instructions if needed just like computer code can generate other code, update rules, and modify data that change how the program operates. A program is made up of activities, procedures, and work instructions or as the programmers know it, the class, the methods, and the program statements.

Metrics for a process are built in from the start and can be injected into computer code or built in to the abstract base of the code. In business, the best place to think about your metrics for success design patterns. I admire Peter Coad who tried to assign roles to classes and discover some reusable patterns for interactivity and not just static recipes. is during the planning stage so you can always build with them in mind or else you'll have trouble retrofitting them later. Roles of who should be involved in the process are important. In code, the types of relationships that you maintain with other code is important and successful relationships are spelled out in recipe books called

Process improvements are always a part of all processes and can be found in wrap-up sessions or project post mortems. In code we get a closed feedback loop from the folks who are using the programs who give us reason to enhance the program and get more financing for the next maintenance project. Feedback comes in the form of new or improved features and it gets added to the system as the value becomes known.


- Doug Hoff, Business IT Expert; MCT, SCJP, ITILv3, COBIT LinkIn with Doug