10K Hits

Free website traffic to your site! Medium Rectangle (300x250) Square (250x250) Button (125x125)

Thursday, July 27, 2006

Web 2.0

As I've discussed before, major technological drivers behind Web 2.0 are web services mashups and AJAX. AJAX, or Asynchronous JavaScript and XML enables a desktop-like experience and interactivity via a browser. Mashups, on the other hand, allow for web services to actually run over the public Internet.

It is no surprise then that these new technologies open the doors to new ideas--and thus new entrants--into the SaaS market. Venture Capital money has poured into a number of Web 2.0 startups, and Esther Schindler at IT Bussiness Net reviews three such Web 2.0-based CRM startups in CRM for the Web Crowd. Below is an excerpt:

[M]ost of the well-known Web 2.0 sites, such as MySpace.com and digg.com, are inherently consumer-oriented. While a business site can use some Web 2.0 elements, such as location mapping features, few of the Web 2.0 developers are putting their attention on the needs of corporate users.

One exception is Customer Relationship Management (CRM), long a standby of the sales and marketing crowd, and low-hanging fruit for a developer looking for a problem to solve. Once, applications like Goldmine were strictly desktop applications; now they've moved to the Web. It's a crowded market for any CRM vendor, so I gave a cursory look at three sites listed in the Web 2.0 category -- 24SevenOffice, Pushcrm, and Zohocrm -- to see if the substance matches the hype.

RIA and Usability Concerns

RIAs (Rich Internet Applications) are not any different from other software solutions. Developers need to follow some basic User Experience design principles. They have to choose the right design to fit the right context of use against what we know about
users' cognitive capabilities.

The warning to development teams not to be too enthusiastic with new and cool technologies. This is what initially led to Jakob Nielsen's decree that Flash is "99% bad." Most of the challenges associated with developing RIAs are design issues and not technological problems.

How Developers Deal with Design Problems

The only way they can know if their application works well for users is through testing. One technique is for development teams to test an existing RIA. How are people using applications such as Yahoo Mail Beta, Gmail, and Zimbra? The best thing about design is that you never have to feel the need to start from scratch.

Developers can also leverage new design conventions. The Yahoo Design Pattern Library is an amazing resource to help teams out. Developers have fallen into the copy-cat design methodology. Conventions are guidelines and not rules. They can be extrapolated upon easily and creatively to evolve into new conventions. So look to examples for guidance, but not for solutions.

Some of the benefits of developing applications using AJAX

AJAX lets designers add rich interactions to ordinary HTML-based pages, as either a whole architecture solution or an incremental fix. Since it doesn't require a plug-in, it is the easiest RIA technology to deploy.

It allows a subsection of a screen (or page) to act independently. This helps developers and designers mitigate a big pain point in standard HTML solutions -- the full page refresh phenomena. In standard HTML, every time you need to fetch information from the server, the entire page will disappear and redraw, even if only a section needs to change. AJAX gives designers control over both subtle and dramatic changes in the

The best example of this is in both Gmail and Yahoo's new Mail Beta. When you begin typing an address or name, they attempt to auto-complete it, refining your choices as you type. On each keystroke, it is refreshing a query against your address book (and history), presenting you with the total list of matching addresses, all without a page refresh.

AJAX has become sooooo popular

I think the primary reasons for its popularity is that it is all open and is an extension of the same technologies that web developers are using today. There is not a lot new here. It is an extrapolation of existing logic in the current collection of web development languages: HTML, JavaScript, XML, and CSS.

Also, there has been a strong community of eager developers who have seen AJAX-like applications as a holy grail, to add appropriate richness to their applications without having to be tied to anything but a browser -- no plug-ins at all.

AJAX as a technology has existed for quite a long time, even dating to the last millennium; MS IE 4.0 came out back then and JackBe has been around for five years. But it wasn't until 2005 when more and more applications began ignoring browsers that didn't support AJAX (whether or not they were using it.)

The last piece that has come together is the push towards Software-as-a-Service (SAAS) and browser-based applications. People want to subscribe to applications instead of buying a license. AJAX affords the desktop-like behaviors that user’s desire.

New technologies

Instead of blindly upgrading to RIA applications, development teams need to ask themselves if the technology offers benefits not possible otherwise. For example, are there places where using a different page metaphor would be advantageous for their
solution? Are there opportunities to reduce the frequent page refreshes on their projects? If this type of questioning bears fruit, then the development team should consider a new technology such as AJAX.

If the team wants to try their hand with an RIA technology, they can start with "quick wins" like address book suggestions, or search suggest, or single field view/edit (think ratings in NetFlix). Use these quick wins as both technological and design proofs-of-concept to gain support for bigger page-metaphor changing designs later.

Are Rich Internet Applications are setting the standard? Are there some that just "get it" and could serve as valuable examples for those trying to learn more about them?

I think Google's Gmail ( http://www.gmail.com ) demonstrates the new page metaphor best. Gmail, as a poster-child AJAX solution, does very well to maintain common web conventions.

Kayak ( http://www.kayak.com/ ) and FareChase ( http://farechase.yahoo.com/ ) really demonstrate how to manage a complex dataset without making new calls to the server. With its new redesign, Flickr.com ( http://flickr.com/ ) has set a new standard for desktop application design without it looking like a desktop application. I'm really impressed with what this team has done. Menus, inline, and editing are really done well.

To me, the new Yahoo Maps Beta ( http://maps.yahoo.com/beta/ ) is just spectacular. I prefer it over Google Maps ( http://maps.google.com/ ) in spirit, but between the two it is

a toss-up. Google succeeds in one place where Yahoo doesn't -- simplicity of entry. Yahoo is still too hard to use, while Google still doesn't have the right output and features. These are a great example of how total experience is important to make a solution truly succeed. There is definitely a middle ground waiting to be designed for.

Pitfalls that AJAX introduces

The biggest pitfall of almost all RIAs is accessibility. They often don't work very well with screen readers and other third party accessibility devices.

RIAs also often work differently from how users expect. Since AJAX-enabled applications are still in the browser, users expect them to act like the traditional HTML-based web applications they're used to. It's a real challenge to present old interaction

behaviors like drag & drop in a new context. The favorite criticism of most RIAs by web purists is that it kills the "Back Button." It is true that the back button does have to be managed, but there are aspects of the browser that "get in the way" of trying to do desktop-like behaviors in a web browser. However, you can succeed at having a pretty rich interaction model and still allow users to use the back button.

AJAX or Flash

On the consumer-based web AJAX and Flash are pretty interchangeable. When choosing between AJAX and Flash, developers need to think about what kind of experience they want to give their users. If they want to offer users a more cinematic experience, Flash is the best choice. This really has to do with the limitations of JavaScript and the primary purpose of Flash to make interactive animation pieces. Other than that, AJAX is the clear scaleable winner.

Skills Successful RIA Developers Have

Well, they first need to understand design. I suggest they take a studio course for at least a semester. Learning a design discipline will take you further in your design career than any Flash or Photoshop class ever will.

To be successful at any creative endeavor you need to have 3 components: craft, critique, and theory. For an interaction designer's Craft, they need to know graphic tools, prototyping tools, programming languages, databases, frameworks. For Critique, a designer needs the ability to view and evaluate their design work. For Theory, designers need to understand the principles of HCI, game theory, visual design theory, and general design aesthetics.

Wednesday, July 26, 2006

Rules for visiting Wisconsin (humor)

On Visiting Wisconsin This Summer - Do it, Then Go Home
Posted on 06/17/2004 11:24:06 AM PDT by Peace4EarthNow

1. Don't order filet mignon or pasta primavera at Al's Lodge. It's a diner. They serve breakfast 24 hours a day. Let them cook something they know. If you upset the ladies in the kitchen they'll kick your ass.

2. Don't laugh at the names of our little towns (Sheboygan, Mukwonago, Onalaska, Oconomowoc, Nekoosa, Pewaukee, Wauzeka, etc.) or we will just have to kick your ass.

3. We know our heritage. Most of us are more literate than you. We are also better educated and generally a lot nicer. Don't refer to us as a bunch of hicks or we'll kick your ass.

5. We have plenty of business sense. You have to make a living here, unlike some places where people are allowed to live off parents past the age of 16. Naturally, we do sometimes have small lapses in judgment from time to time, but we are not dumb enough to let someone move to our state in order to run for the Senate. If someone tried to do that, we would kick her ass. We are also not dumb enough to elect a Professional Wrestler to our highest state office. People like that should have their ass kicked.

6. Don't laugh at our giant fiberglass fish and cows. Anything that inspires tourists to buy 50,000 postcards can't be bad. And don't laugh at our love and pride of cheese or we'll kick your ass.

7. We are fully aware of how cold it gets here in the winter so shut the hell up. Just spend your money and get the hell out of here or we'll kick your ass.

8. Don't order the vegetarian special at the local diner. Everyone will instantly know that you're a tourist. Eat your steak well done like God intended and have some potatoes with that, for heaven's sake! Also, don't ask what a hot dish is or we'll kick your ass.

9. Don't try to fake a Wisconsin accent. We don't have an accent. That will incite a riot and you will get your ass kicked many times.

10. Don't talk about how much better things are at home because we know better. Many of us have visited big-city hellholes like Detroit, Chicago, and New York and we have the scars to prove it. If you don't like it here, Interstates 90, 94, and 43 are ready when you are. Move your ass on home before it gets kicked.

11. Along the same lines, don't try to tell us we don't have beaches like California, Virginia, Florida, and North Carolina. We got two great lakes, lakes up the ass, and the biggest river on the continent. You knock our beaches and we'll kick your ass.

12. Don't complain that Wisconsin has too many mosquitoes and farmland. If you whine about OUR scenic beauty we'll kick your ass all the way back to Chicago.

13. Don't ridicule our mannerisms. We only speak when spoken to. We hold doors open for others. We offer our seats to old folks because such things are expected of civilized people. Behave yourselves around our sweet, little gray-haired grandmothers or they will kick some manners into your ass just like they did ours.

14. Don't lie to any of us. If we don't find out right away, we will eventually. We will then kick your ass.

15. So you think we're quaint or losers because most of us live on the farm or in the woods? That's because we have enough sense to not live in filthy, smelly, crime-infested cesspools like New York or LA. Make fun of our fresh air and we'll kick your ass.

16. Anyone from any point further south than the Mason-Dixon line will have their ass kicked back to whence they came. If you are from Virginia, we will kick your ass using some LaCrosse Steel reinforced boots.

17. Oshkosh B'gosh is NOT a joke. Your ass will be kicked.

Enjoy your visit and then go home.

Tuesday, July 25, 2006

Rich Internet Applications Based on Ajax, Flash, and Java Will Quickly Supplant Current Static Web Applications and Portals

July 25, 2006, ZapThink

BALTIMORE--(BUSINESS WIRE)--July 25, 2006--ZapThink released a report today showing that demand for Rich Internet Applications (RIAs) and more sophisticated user interaction is increasing dramatically. RIAs provide an end user experience that combines the experience that users are most familiar with in desktop and client/server applications, such as rich graphical user interface, responsive performance and highly interactive functionality, with the scalability, distribution, and manageability benefits that Internet applications provide. The report entitled "Rich Internet Applications: Market Technologies and Trends" shows that Rich Internet Applications will continue to gain prominence in the enterprise, with companies spending more than $500 million on RIA applications by 2011.

"Users today increasingly demand more from their online user experiences," said Ronald Schmelzer, senior analyst with ZapThink. "The convergence of SOA and Web 2.0 are leading organizations to retire their static Web pages and inflexible portal applications. Today's set the bar for user interactivity higher than ever before, and expect their online experiences to behave more like the desktop applications they are used to."

ZapThink's report aims to establish the current state of the RIA market, quantify business trends, and predict the future of the RIA markets. In particular, the report identifies emerging classes of business problems that RIA solutions target, current and future trends for spending on RIA solutions, the primary technological RIA approaches, average RIA deal sizes by technology and business problem, overall RIA market sizing, and categorization of RIA solutions by segment and market approach.

Other key findings of the report include:

  • The market for RIA solutions consists of three submarkets focused on delivering RIA components, environments, or extensions to Integrated Development Environment (IDE) suites.
  • There are four primary means for providing RIA capabilities: Adobe Flash virtual machine-based approaches; browser-based approaches that use JavaScript, XML, and other technologies, also known as Ajax; approaches that use Java applets or ActiveX controls; and custom-developed Java or .NET clients.
  • A set of six key business applications are motivating overall RIA spending consisting of enhancement of existing web applications: high-transaction and event-driven Internet applications, next-generation portals, enhanced business intelligence solutions, application modernization, and Service composition or so-called "mashup" solutions.

The report, available on ZapThink's Web site at www.zapthink.com, discusses several companies, including Adobe (NASDAQ: ADBE), Altio (division of Integra SP), Backbase, Curl, DreamFactory, General interface a division of TIBCO (NASDAQ: TIBX), ICEsoft, Ideo Technologies, JackBe, Laszlo Systems, Macromedia (now part of Adobe), Microsoft (NASDAQ: MSFT), Nexaweb, SCO Group (NASDAQ: SCOX), Zapatec, and ZK, among others.


July 21, 2006

Venture capitalists are going nutty over Web 2.0 companies, pouring $870 million into these companies during the first three months of the year, up from $786 million the quarter before, according to a new study by PricewaterhouseCoopers and the National Venture Capital Association.

Here is a list of all Web 2.0 companies that received venture backing. Download the list here; note the tabs at the bottom, which show all 2005 fundings, and then 2006 Q1. Scroll to right to see the funding amounts, etc.

Monday, July 24, 2006

Twisted Sister

Here I was introducing my girlfriend to the state in which I grew up in and what better way to do that than take her to a good ol' Wisconsin Waukesha county fair. Besides the fried cheese, cheescake on a stick, and cream puffs, who could we have been blessed with mainstaging? Yes, that's right. Twisted Sister; and they rocked. What a way to introduce my girl to the state I love. Needless to say I don't think she had developed a Wisconsin stomach yet. Below is a pic of her after two days of traditional foods such as mentioned above but also including fish frys, and brats with krout. At least she doesn't look as bad as Mel Gibson's mugshot photo.

Dee Snider is an avid advocate of the March of Dimes. You can sponsor Dee Snider in the Annual Bikers for Babies Ride to benefit the March of Dimes.

Thursday, July 13, 2006

REST and Web Services: The ZapThink Take

By Ronald Schmelzer
Document ID: ZAPFLASH-2006712 | Document Type: ZapFlash

Question: what do you call two or more architects in a room? Answer: an argument. Now that Service-Oriented Architecture (SOA) is the topic du jour within many such rooms in enterprises today, one favorite argument is over Representational State Transfer (REST) and its relationship to Web Services. Many such discussions degenerate into a religious discussion over which approach is better, but as with most arguments in the SOA space, the reality is far more subtle. Up until now, ZapThink has been happy to stay on the sidelines of this battle, but the time has come for us to weigh in with the ZapThink take on the REST vs. Web Services debate.

The Context for REST and Web Services
This perennial debate centers on a core challenge of SOA: what is the best way to create a loosely-coupled Service interface? One approach is the style of distributed computing known as REST. REST depends on the Hypertext Transfer Protocol (HTTP) as a stateless client/server protocol for exchanging information in a request-response manner utilizing a simple set of well-defined operations: POST, GET, PUT, and DELETE. In REST, a resource is exposed using a Uniform Resource Identifier (URI), which often looks like a Uniform Resource Locator (URL) familiar from the Web. The idea with REST is to change some state of a resource, rather than calling some procedure on a remote system, as traditional Remote Procedure Call (RPC) methods of distributed computing mandate.

To illustrate this point, REST might call for a resource type Customer which might have hundreds of exposed URIs. For example, http://mysite/customers/insurance/rschmelzer might refer to my customer record in an insurance application. To modify information in that record, the user would POST or PUT an XML file into that URI and then GET that information back in a subsequent call to the URI. The key is that REST uses “nouns”, not “verbs”. Instead of making a call to a function called getcustomer and passing it a customerID, REST indicates that users make a call to a resource called customerID and throw some XML at it.

From a REST perspective, we don’t really care about the architecture of the underlying solution. We can leverage REST for n-tier applications or client/server solutions, just as easily as Service-oriented approaches. Indeed, any application can be “RESTful” if it exposes capabilities through a GET request via HTTP. While REST certainly aims for simplicity in distributed computing, its primary challenges are identifying and locating individual resources and building asynchronous, event-driven styles of interaction. The lack of standards for REST other than HTTP and XML also presents a challenge for both vendors and IT shops. In addition, we are still left to grapple with issues of semantics – that is, what exactly goes into that XML that is exchanged between clients and servers?

In SOA, however, a Service does not necessarily map to a resource, but rather to a set of operations or a composite business process. Indeed, a Service maps more closely to the concepts of capabilities and processes more so than the resources that those capabilities and processes act upon. In this regard, a Service may be exposed as a resource, and a resource might expose a Service, but there’s no a priori equivalence between Services and resources.

RPC vs. Document-Style Interactions
The real contrast, therefore, is not REST vs. SOA, but rather the conflict between REST styles of Service implementation and Web Services styles that have an operation-specific perspective. Keep in mind that Web Services don’t represent an architectural approach, but rather a set of standards for how we define Services (WSDL), communicate with Services (SOAP), discover their availability (UDDI), and perform other value-added security, reliability, composition, and management tasks. Services are abstractions to code, and thus don’t represent instantiations of code. That is to say, you can’t run a Service. You can only expose Service interfaces to underlying code that may or may not be Service-oriented. Since Services can’t run, the only thing we can focus on are the metadata-based interfaces and policies that govern the definition, interaction, and management of Services and their composition into business processes.

Services don’t focus on resources, but rather on operations. A Service might have many operations, dozens or hundreds, in fact. Each operation specifies a particular behavior for how the Service will handle incoming XML documents and produce corresponding results. However, at this point we’re posed with a challenge. Do we define a single WSDL document that specifies a Customer Service, with multiple operations for creating, modifying, and deleting records, or do we create multiple Services, each purpose-built for a specific operation, but accepting different XML documents to handle different use cases?

This question gets to the heart of the matter in discussing the difference between RPC-style and document-style approaches to Web Services. In the RPC style, Services are treated as if they were objects with methods, requiring a SOAP call to address a specific operation with a specific method call to evoke a response. The XML message in this instance looks like a call to a method, with parameters and functions. For example, we might call the getCustomerName operation on the Customer Service and pass an XML document that looks like 1234. Thus, the RPC style requires that Service consumers know not only the specific operation they wish to call, but also its method and type. As a result, RPC is a tightly-coupled approach in which any change to the operation or method requires significant change to the Service consumers.

The REST approach contrasts starkly with RPC, where an object called Customer would have a multitude of operations for creating, deleting, and modifying records, with multiple, discrete instances of objects each referring to a different customer. Fundamentally, therefore, REST is more like the document style, which also contrasts with the RPC style by requiring only that Service consumers know the operations they wish to call. In the document style approach, we simply call the Service we want and pass it an XML document that the Service can process any way it wants. So, we might call the CustomerInfo Service and pass it an XML document that it is contracted to accept. In turn, the Service consumer would receive an XML document that it is expecting, as per the contract, with no reason to call any methods or specify any data types.

As a result, the document style offers a greater degree of loose coupling than the RPC style, since any changes to the methods or operations might have very little impact on Service consumers. In addition, the XML body of a document-style Web Services interaction contains the actual business message – the valuable stuff. Whereas in the RPC approach, the XML typically just describes the methods and parameters of the method call.

The fundamental difference, therefore, between REST and document-style Web Services is how the Service consumer knows what to expect out of the Service. Web Services have contracts, defined in WSDL. Since Web Services focus on the Service, rather than on the resource, the consumer has clear visibility into the behavior of the various operations of the Service, whereas in REST’s resource-oriented perspective, we have visibility into the resources, but the behavior is implicit, since there is no contract that governs the behavior of each URI-identified resource.

In REST, you are requesting a change to a state for a particular resource, but you aren’t specifying the operation. Indeed, in REST, the operations are all the same: GET, PUT, POST, and DELETE. But what these operations will actually do (some call this the “application protocol”) differs on a per-resource basis. If you have a resource-oriented view with the perspective that REST is an architectural style (as many do), then RESTful Services are exposed as a type of resource with constraints to ensure loose coupling and composability. If you take a Service-oriented perspective on enterprise architecture, however, then REST represents an implementation style for exposing Services that has as much validity as the document style of Web Service interactions.

The ZapThink Take
ZapThink champions Service Orientation as an approach to addressing the needs of the business with collections of Services that represent complex and changing business processes that in turn compose other Services. As a result, how to implement those Services is an implementation decision that can leverage a variety of technological approaches including REST or document-style Web Services. In other words, the debate over REST vs. Web Services is moot, as the question boils down to which is the right tool for the job.

The real challenge to applying REST as a means to implement loosely-coupled Services is that REST has no explicit contract to define behavior, which means that all behaviors are implied. In REST, the data pumped through a GET, PUT, or POST operation contain all the semantics necessary to understand how a Service behaves. Therefore, REST isn’t appropriate for organizations that wish to take a contract-first development approach aimed at maximizing reuse and composition, in addition to loose coupling. And that’s the rub with REST – SOA aims to reuse not just the resource, but also the operation and the composition as well.

In many ways, however, the debate about Web Services and REST is as pointless as arguing whether a hammer or a screwdriver is a better tool. While each of the approaches add specific value to exposing Services and resources, SOA is an overarching approach for dealing with ongoing change in a business environment. The business doesn’t care about the resources or even the Services themselves, but rather the business value that result from interacting with those resources and Services. It’s up to the architect to understand when to apply different architectural and implementation styles to best address their organization’s ongoing business challenges

Tuesday, July 04, 2006

'Midwest' Discovered Between East, West Coasts

The Onion

A U.S. Geographic Survey expeditionary force announced yesterday that it has discovered an unexplored and heretofore unknown land region between the New York and California coasts.

Enlarge Image'Midwest' Discovered Between East, West Coasts

"We shall call this land 'the Midwest,'" said Dirk Zachary, New York City native and leader of the 200-man exploratory team. "And its primitive inhabitants shall be known as 'Midwesterners.'"

Zachary and his men discovered the region while searching for the fabled Midwest Passage, the mythical overland route passing through the uncharted areas between Ithaca, NY, and Bakersfield, CA.

"I long suspected something was there," Zachary said. "I had flown between the city and L.A. on business several times. The duration of my flights seemed to indicate that some sort of a large area was being traversed, an area of unknown composition."

When asked if he had ever looked down from the airplane window during his flights, Zachary said, "Why, no."

The U.S. Geographic Survey's expedition left the East Coast three weeks ago to mixed hurrahs and jeers. Not long after crossing the Adirondack Mountains, Zachary and his team were blazing trails through strange new regions, wild lands full of corn and wheat.

"Thus far we have discovered the places known as Michigan, Minnesota and Wisconsin," said Thomas Higgins, chief navigator for the expedition. "When translated from the local dialect into human speech, these words seem to mean 'Summer camp.'"

Zachary and the others were surprised to learn that the Midwest, long believed to be incapable of supporting human life, was indeed populated, albeit sparsely.

"The Midwestern Aborigines are ruddy, generally heavy-set folk, clad in plain non-designer costumery," Zachary said. "And though coarse and unattractive, these simple people were rather friendly, offering us plain native fare such as 'Hotdish' and 'Casserole.'" Despite the natives' friendly demeanor, Zachary's men quickly slaughtered all Midwestern tribesmen they encountered, "just to be safe."

Though the Midwest is still largely unexplored, early reports depict a region as backwards as it is vast.

"Many of the basics of a civilized culture appear to be entirely absent," said Gina Strauch, a Los Angeles-based anthropologist. "They have yet to discover the film industry, and their knowledge of restaurants is sketchy at best. Their agri-centric lives seem to prevent them from exploring the high-fashion sciences to any degree. Further, many of their children earn money at actual 'jobs,' rather than spending their parents' money or living off a trust fund."

Despite the cultural differences, some say relations with the Midwest are possible.

"Believe it or not, this region may have things to offer us," said James Ogleby, a San Francisco marketing expert. "We could build an airport there, a place where passengers could switch planes on their way across the country. We could send touring Broadway productions there to stage revivals. We could even someday conduct trade with the Midwesterners, offering them electronics in exchange for cattle."

Despite the excitement over the discovery, Zachary is maintaining perspective. "These people are not at all like us," he said. "They are crude and provincial, bewildered by our cities and our culture, our books and our coffee shops. For a New Yorker to attempt to interact with one as he would with, say, a Bostonian is ludicrous. It appears unlikely that we will ever be able to conduct a genuine exchange of ideas with them about anything, save perhaps television or college football."