Showing posts with label web service programming. Show all posts
Showing posts with label web service programming. Show all posts

Tuesday, April 8, 2008

ROI: The 800 lbs Gorilla in the Corner pt 1

Token Ring LAN Logical Network Layout with three hosts connected to a Multi-station Access Unit (MAU). Ring in/out ports are not shown for simplicity.Image from WikipediaA lot of the stuff I do is difficult to present in terms of ROI: web development and programming, software training, SEO/SEM, and Community Building can be very esoteric in terms of raw dollars.

Old Days
It's been like this since my first days in the computer field.
My second job in IT was as a commission sales person for NEC. To the world back then, IBM meant Computers. NEC was unknown outside Japan. They entered the US market through Europe with a superb microcomputer system based on the new 286 processor. (I did warn you I'd been at this a long time, right?)
Not only was the system faster, but it had the best color monitor on the market. It could be networked - with a little careful programming- with the new Netware software, so it didn't need a license for token ring technology from IBM.

I didn't know much about programming or computers in those days. All I knew was I wanted to work with this cutting edge stuff. Fortunately, microcomputers leveled the playing field for folks like me. Colleges were training people on mainframes. Even people with Masters' degrees in Computer Science had rarely seen a micro.
My only real advantage was to be organized. I might not have had much more to say than what was in the brochure, but I made sure I got to every appointment on time to say it.
I was really excited to be working for one of the obvious industry leaders as it expanded into a vast new market.

This one manager was impressed with my naive enthusiasm. On the second visit to his distribution company, he smiled and told me: "If you can find me one piece of software that will run on that system, I'll replace every computer in the room." I looked across the room at 25 computers, and my pupils must have dilated.
Then he said, "I'll replace them all,...if you can find me one piece of software that will run on 286 systems." Then he handed me a copy of DataSources. DataSources was once the Bible of the computing industry. These two huge books were 4 inches thick and the size of a coffee table book. One was for software. One for hardware.
"Go ahead. You can take them with you. You find one piece of software, even if I can't use it, and I'll sign the requisition today," he said. "Then come talk to me next week."

I took those books home and poured over them. I even looked through the hardware book hoping to find something to trace down in the public library. There was nothing.
I had to go back in there the next week and admit defeat. He just laughed as he handed me some coffee.

The new DataSources came out in about 6 months. It was filled with software that ran on 286 systems, and software that was compatible for both 286 and 8080 systems. Both had options to use CP/M, PCDOS or MSDOS as the operating system.
Turns out, he did replace all his computers, networked them, and signed on to an annual service contract to contain his costs - all through me. I ended up doing a lot of the work myself. I followed the NEC tech around and helped him to learn about all the new technologies.
The owner and I had a lot of coffees together.

This was the days before the Internet and Windows. Windows was out, but version 2.x didn't work reliably. It was a year or so later when version 3.1 came out that Windows began to make a place for itself.
The Internet was a secret subject for tech people. We wished upon the stars for it. It was more an impossible dream than reality. And many people thought it would never happen. The Internet would mean too much information and freedom, the hacks canted. No government would allow that.

Faith?
Thing is, this guy didn't replace his computers because he could show a real return from the dollars spent. He didn't buy them because he needed the fabulous 10Mbyte harddrives, or the advanced CGA graphics.
There wasn't any way to calculate an ROI on so many unproven technologies. The technologies were so new no one knew how much it would cost to keep them running. Netware was promising to make micros work like mainframes. It sounded almost impossible.
It wasn't hard for IBM to show that converting paper records to searchable databases saved money and increased productivity. But that was for big business with hundreds of thousands of records. IBM had whole systems: printers, terminals, harddrives, and mainframes.
No one even knew how to connect printers to these new microcomputer networks. In most cases, a programmer had to write a driver for a Netware network. How do you figure that cost into the ROI?

IBM threatened, then released their own Personal Computers. But they didn't even connect to the mainframes. PC's worked like dumb terminals which cost much less. IBM only got into the microcomputer market to quash the upstarts.
We know now it didn't work. But when this guy bought that room full of micros and networked them, he could not have justified it to anyone.

So ... Why did he buy 25 computers, a network, and a long term service contract on unproven technology and put his whole career and business on the line?
  • Part of it was the excitement of the microcomputer revolution.
  • Part of it was a need to keep technologically ahead of his competitors.
  • Part of it was to keep up his company's reputation.
  • Part of it was NEC's international reputation.
  • Part of it was all the times I came to him over coffee so many times to tell him exciting and good news about the developing industry.
He made the right decision. But he only saw the ROI in passing. I doubt he ever sat down to figure it all up. If I had had to justify the purchase in terms of his return on investment, he would never have made the purchase.
Many times, I've sat down with prospective customers and told this story.
I emphasize the brilliance of his foresight by quoting Napoleon "L'audace. L'audace. Toujours, l'audace." Then I mention the practicality of the long term service contract which guaranteed him support any time, and specified hourly programming fees - and how that limited his exposure to the uncertainties.

Options
Could he have made safer, more productive choices? Maybe. No one knew it at the time, but his network absorbed technology and upgrades for almost a decade. Netware upgraded to accommodate 386 systems and software, then 486 systems.
If he had networked 8080 or Z80 systems with Netware, it would have been much more risky.
Software is defined for workers in terms of the interface. The costs of retraining staff would have been much more dramatic to move from green text on black screens to 16 and then 256 color monitors.

Color screens turned out to cause less eyestrain, headaches and were proven to be more productive. People were more willing to put in long hours and could concentrate easier on choices distinguished by different colors.

NEC did not offer a long term contract for support on such an ad hoc (technologically) network. Programming and technical support would've had to be billed at the market rate. Netware was made to run on the 286 (or at least the 8086/80186).
Replacing 286-based systems turned out to be much less expensive because IBM opened up its architecture (in a last ditch attempt to bury micros, many thought).
But no one could have known all of that.

What does this story prove?
As the story unfolds, many advantages showed themselves:
  • color screens for productivity (and employee moral);
  • harddrives saved server time;
  • projects and departments were separated for security and practicality;
  • improving technology melded software and hardware to reduce upgrade costs;
  • Microsoft broke free from IBM and Windows came into its own;
  • and much more.
Today we have the advantage of those years of anticipation and determination. But still, many purchases come down to prioritizing the goals of the business. That's really how this forward-thinking manager made his decision.
Look back at the list of reasons I gave. Then glance over the whole article. Not many of those elements could be expressed in hard numbers going in. They had to be managed to prove themselves.
And there is an element of just plain luck.

He chose to make the purchase because of his own priorities. His priorities were not easily quantifiable. There is no question they are qualifiable though. And in time some of his qualifiable reasons proved themselves.

The story illustrates a reality of any technology purchase: hardware, software, training, websites, SEO/SEM, and community building, the decision is made on priorities, not necessarily hard numbers. Technology in business is too closely integrated with ergonomics to quantify everything. Employees and customers are a part of the equation.
If the technology is not a priority, it will not be purchased no matter what is quantified.

Does that mean not to put into numbers anything that can be quantified? No. At every opportunity, quantify. Managers need numbers to manage. It's an old adage of management.
But management at every level has to respect the elements of technology that are qualifiable, but resist being quantified.
We'll explore these topics further in the next few posts in terms of each of the services and products.



SEO/SEM in Australia is a special issue for so many reasons. Join me was we explore. It will be a fascinating and informative journey.
Sphere: Related Content

Sunday, March 16, 2008

Web Design 101 - First Period

I am, by my own admission, a lousy web designer.

Why? - Because I hate templates.

The first website I saw was made by Microsoft's FrontPage 97. All you had to do was tell it: Make me a corporate web! - and FrontPage would dutifully generate homepage, about us, products, and services, and contact pages. Poof! A small company was IBM.
The title of the page was in a box at the top, and all the structural tags - H1, H2, etc. - were colored, sized, and decorated for you. In most templates, it even gave you little graphics for unordered lists.
All you had to do was fill in the blanks, and you were a working company on the Web.
It was a raving bore in 94; and it's only more today. (Not a great poet, either, you'll notice.)

One of the first rules of web design is to make your pages look pretty much the same. The idea is that you won't confuse your visitors, and maybe even establish your corporate or personal style.
That was find in those days if your sense of style is either blue jeans or polyester slacks.
Problem was, that layout implied a company had to have Products and Services. Some companies didn't. That alone created a sense of insecurity or desperation.

Design the information to express

I've never been much of one to put things in little boxes. Design should express and enhance, not restrict.

I tend to want to design a website page by page to reflect the present attitude of the company. If it's a small company that just got a new logo done, then let's let it fill half of space above the fold. Why not? This is company just coming into its own.
They're proud of their new logo. It's all over their vans, new business cards and new company literature. Put it out there for the world to see!
They've only got a few services, but those services are needed in their area. Their customers like them. One of them said so right in the middle of the home page.
Just put a list on the side full of links to get more info.

A design like that gets poo-poo'd a lot. Even customers don't like it because they don't think it looks "business-like". (Not that anyone has ever defined "business-like" too well.) It becomes a matter of latent expectations, not perceiving.

Why does a web page have to follow the pattern of a business letter? Why not let it be a presentation right from the homepage? You got a new company, tell the world about it.
You can always add or adjust stuff later.
It has to look like a business letter because customers won't know what to do. Or, It has to look like a business letter because that's what this site looks like. (The one I'd like to be...)

Wired wonders
Wired proposed over a decade ago that we use the web space better. (I lost track of the article or I'd provide a link.)
Web pages only had to show a window into the content. It's what they do anyway. There could be content spread wide and far across thousands of pixels of space. One click, and the viewport shifted to another part of the grandscape.
They were far ahead of their time.

Web pages in those days were constrained by download speeds on 33k and 56k modems. If a webpage had more than 30K of content - images, programming, and HTML - visitors just went somewhere else.
The download time has changed a little with the spread of broadband, but the size limitation for templates still holds them below 60K. And all of it has to fit on a business letter, within two clicks down the sidebar.

The article proposed broad, bold colors. Wide colored channels guided the visitor across the webscape to explore information or make a purchase. The user actually interacted with the page instead of just clicking away.
Changing colors in the viewscape indicated where the visitor was in the process. All the information was contained on the page, so there was no need for flickering screens. The body tag encompassed many pages, really viewports, of the viewscape. If the visitor wanted, they could ramble around without following the colored guide lanes - and take the path less followed.
Using a mouse or the arrow keys, they could go anywhere just like exploring a landscape on Google Earth. Zoom in or out to get their bearings, then off to explore again.
I don't imagine such a site would have a problem with stickiness...

Where does all of this fit into SEO and SEM? That's going to be a topic or two for another time.

The plan in those days long ago was to use Javascript and Java to implement responsiveness and new content on demand. That can still be done, of course, but there are much more exciting options now. (continued later)

SEO/SEM in Australia is a special issue for so many reasons. Join me was we explore. It will be a fascinating and informative journey. Sphere: Related Content

Monday, October 1, 2007

Polls: How longdoes it typically take you to make a webpage from scratch?

From About.com:

I love Jennifer Kyrnin. She knows how to keep her readers interested by motivating feedback.

It seems like a pretty straight-forward question at first glance: How long?
Interestingly, it's easy to see that the more experienced web designers said it took them longer to make a web page.

Inexperienced page designers will simply layout a page, insert a few graphics and set the text layout to suit. Concerns such as SEO - many inexperienced page designers avoid the head tag altogether - keywords, and competition can be forgotten.
(The worst is subcontracting to someone who has sold a web page/site design to a client from all Flash, but that's another post..)

Experienced page designers are aware that every page is in competition with other pages all over the Net with the same topics and similar content. A good designer will keep this fact in mind and research competing pages from keywords and search listings.
To ignore the basics of SEO when designing a web page is hardly fraud but it comes close. At best, it's unprofessional. Without SEF considerations, a web page is just a prototype or mock-up. If that's what the client is paying for, good. But an ethical designer will tell them they don't have a functional web page no matter what widgets or devices are included.

27% of the poll respondents indicated they could make a web page in 'an hour or so' or less.

46% indicated it took 'half a day' or 'a day or two' to design a web page from scratch. If the page is in XHTML using good software, that sounds about right.
Now, if there are other considerations, such as scope creep (Client or designer keeps adding new things and ideas.), or the page is intended to work with a CMS or embedded devices that are integral to the presentation, a page can take longer.
It's a good rule of thumb that you can add the number of scope creep plus the number of devices as a percentage to the increased cost of a web page. Any total over 10 means the cost doubles - which often means adding a new page or two.

Pricing alone quickly becomes a sticking point, especially when there is a wide disparity between the skill level of the designer and the client. Price and useability (as the client understands it) can quickly push the time required into the 'a week' and 'more than a week' categories from the poll.
A better professional position for the designer is to avoid adding to the scope creep, even if it's hard to manage the creative juices burning inside. Somewhere between the unhappy knot of understating "Give the client what they want.", and those creative juices is a happy compromise for all.

It's a paradox of human nature that the web pages that take the longest are probably those where the designer is given free reign, - no matter what the price!
Designing for oneself is probably the worst example. The designer cannot keep the scope creep under control.
Designing for someone who has already paid - even if it's a small price - with freedom of design is a close second. The showmanship of the designer comes into play. S/he cannot avoid the tendency to want to show what they can do. Time constraints be damned.
It becomes a no-sum game between the goal(s) of the page and the skills of the designer.
Next comes the situation where it is the first work done for a large, prospective long-term client. The designer has to remember that the work follows the bureaucratic model: Whatever you do becomes expected, and you have to build from there (- which may be impossible...)
These situations take the longest.

Then there is the undiscovered technology page, where the designer wants to use a new technology and the client has no idea what is happening. Oh well.

SEO/SEM in Australia is a special issue for so many reasons. Join me was we explore. It will be a fascinating and informative journey. Sphere: Related Content

Polls: Should you extend credit to clients?

From About.com:

The question isn't as simple as it sounds. There is no web designer/services programmer who has not been burnt by a client. Sometimes it seems like the clients we are most willing to do more for are the ones most likely not to pay. That's some sort of psychological twist built into the creative-technical syndrome (-Did I just invent a new topic for the DSM VI?).

But getting a contract from clients who are woefully unaware of the goals of their own site can be impossible.
In Australia, the level of client awareness is woefully behind the rest of the free world for many reasons. Australians have only had broadband access for a couple of years for anyone outside the central business districts (CBD). Even the best of promised access speeds coming in the next few years are only barely considered 'broadband' by the rest of the world.
Through no fault of their own, the vast majority of Australian businesses have no concept of the power of the Internet.

94.6% of registered businesses in Australia are small businesses. Following the ancient maxim/rule of internet marketing, 70% (or more in a developing market) of sales from a website will be within 20 miles of the physical address of the business. That's approximately 35 kilometers.
The rule applies to about 85-90% of the 3.8 million Australian business owners.
In plain English, these folks just don't see the reason for a website.
At best, the business owner sees that their clients expect some sort of website. Their vision for the website is more along the lines of a business card or brochure. Monetizing the site, or even making it SERP-friendly, is far beyond the mindset.

Extending credit to such clients is risky - with or without a contract.
The poll on About.com is not a good representative sample because of the small number of respondents; and possibly the make up of the respondents, but the message comes through loud and clear: Credit is very risky.

A useful compromise to put everyone's mind at ease is a staged payment system.
Once the goals of the site are outlined and sketched out as webpages, a baseline cost can be determined. This price has to leave some room for a little scope creep, but not too much.
Suggested features should be fixed price alternatives - defined as clearly as possible - and not more than 3-5 listed.
A base rate of some sort has to be agreed upon, either as per-hour, per-page, or some combination.

When the price is agreed upon, at 1/3 to 1/2 is paid up front. An alpha point is determined by the satisfaction of the contracted goals of the site. If there are a large number of pages/features in the site, another payment point should be based on the estimated number of days to complete pages or features.
Like most of us, web designers/programmers like to see pay packets fortnightly or monthly. That's a good rule of thumb for how to break up payment schedules.

Finally, the last payment should be substantial - 1/4 to 1/3 of the completion.

If a client can't agree to partial payments as the goals of the site are satisfied, it's time to find another client. The web designer has already put in hours of research and consultation at this point that s/he will never be paid for; and the 'client' has gained from the free education.

It's nearly impossible to get full payment up front from a contracted project, but we can all hope for somedays..

SEO/SEM in Australia is a special issue for so many reasons. Join me was we explore. It will be a fascinating and informative journey. Sphere: Related Content