 |
     |
||
 |
|||
The only IM client you'll ever needFeb 26, 2008
... because you really only ever need to talk to me, right? Google has just (finally?) released one of its most obvious product extensions but its one with enormous potential. Now sitting in the right column of my blog, the Google Talk Chatback Badge, also here: Click on it, and if I'm online with Google chat, you'll be instantly connected with me. No need to have a Google Talk account of your own. Now these things are nothing new. Google's late to the party as they tend to be, but that trend also calls for enormous simplicity and far-reaching potential implementations. AOL has had some sort of open API for a while, and there are plenty of simple, silly little badges out in the world for leaving "live" or nearly-live comments, chats, etc on blogs and websites. But none of them have been able to make it this easy to interface with a major personal IM provider like Gtalk. Aside from random IMs I may get at inopportune times (don't take it personally if I don't respond right away, or, at all in any given day), the potential applications for freelancers, cheap businesses, one-man Interactive shops (ahem), are pretty cool. Today there are decent services like LivePerson that facilitate online chat-based customer service widgets where a badge not unlike this one facilitates talking to a company's service group. Unlike Google's, a user could leave an offline message, record a chat history, and the company can have a number of other services. But that costs money (around $99/seat/month for LivePerson) that I and a lot of my clients don't want to spend. Having something as simple as a dedicated IM name and this chat badge could make life simpler for small businesses and freelancers everywhere. Which could be Google's long term goal, for that matter. They continue to build their business offerings for small and medium sized businesses with Google Apps for your Domain including Docs, Spreadsheets, Presentations, and Gmail plus services like Google Checkout. As it stands now, Google Checkout is geared mainly for product-oriented companies and not service providers like yours truly (it's kind of a pain, actually). But if they were to improve Checkout and add web-based Widget-driven Customer Service tool combined with bug tracking and collaboration software seen in Google Code - they could have a really easy, web-based suite of tools almost too good to pass up. It's not perfect now and will need some work to get there. Right now, the chats from the website don't appear in my regular IM client (Adium), instead forcing a popup window to chat it. That's annoying, because the last thing I need is a 18th window to sort through. But like most things from Google, it's getting there - and the potential is promising. New Article Released: Playing Nice With GoogleFeb 21, 2008
My newest article for php|architect has been published today and can be grabbed from their website for a low low Canadian price. This month it's "Playing Nice With Google" in which I explore the basics of the GData API for communicating with some of Google's basic data services. They actually have quite a few of their services set up on GData, which opens up a world of programming possibilities.In exploring the format and its features for the article, I was actually quite impressed by it overall. It makes sense, its a relatively simple standard that can extended to meet the unique needs of whichever application is implementing it as its API format - which brings to mind an interesting point. By all accounts, the API standard is not proprietary to Google and is open to implementation by any application out there. Yet I haven't seen much of any GData-compatible APIs out there since it would seem many sites and developers prefer to do something home-grown if they open their application at all. I, for one, intend to create a GData-based API for applications I'm building at work. We're still in the early days of the open and API'd web - but I appreciate services like GData to get us there. A whole book could be written around playing nice with Google for web managers and developers - they have dozens of APIs across a range of technologies and I want to play with them all. In this case, we focused on what PHP developers can quickly dive into - GData: Playing Nice With ... Google Read more of the article in the magazine - available in print and digital formats. The End of an AgeDec 28, 2007
 Netscape is dead. It wasn't the first, but for a while it was the best.The domain, Netscape.com, will live on as a portal that no one really knows what to do with; I imagine with people dwindling away from using the browser fewer will use the site when no one has it as their home page anymore. AOL itself has had little idea what to do with it, changing the Netscape.com business model several times in the last couple years. As usage dies down, so will ad revenue, and eventually, the last shreds of "Netscape" will fizzle into the ether of Lore. Many in both Internet and e-Business circles will ponder on the age that Netscape brought us. Some may say that Netscape and all it represented - its development, it's closed nature and penchant for developing its own brand of markup (IE did as well) during the browser wars, it's spawning of the so-called information superhighway - has no place in our current, transitional, Web 2.0 age. Personally, I think this is just the beginning. Netscape is not the first browser to die, nor will it be the last. The dawning age of the Ubiquitous Internet will bring with it new access paradigms that don't involve "Back," "Stop," and "Reload" buttons. But for now, a moment of silence.           PHP + Salesforce.com Article PublishedNov 30, 2007
The good folks at php|architect saw fit to give me a few pages again, this time for an article about PHP and salesforce.com's awesome Force.com Platform-as-a-Service product. The article was a labor of love, though by the end it was more labor than love, as I found I wasn't entirely sure how to capture all the possibilities in just 4,000 words. But in any case, the article has been published and is available on newstands - you can get in here. Here's how it starts:Once upon a time in a job far, far away, there was a firm that desperately needed a new way of doing things. For thirty years across seven different acquisitions, a dozen separate offices were using whatever means they could to manage their relationships with clients, vendors, and each other. In some offices, the staff still relied on paper order forms passed from the sales floor to fulfillment. Others managed nearly all their processes with email and an Excel® spreadsheet stored on a shared drive. Most offices were linked by some middle-office software for billing and account maintenance, but only a precious few in the company actually knew how to use it. The company was growing, but the staff was ill equipped to handle the load.Get the rest of the article in the November 2007 edition of php|architect. (Incidentally, the article is entitled "Use the Force.com, Luke." I apologize for this title. It was the result of shared exasperation and a looming deadline for both me and my editor, and by the end of it I don't think either of us really cared what to call the thing. Also, there is a misprint on the issue's cover, where the slug refers to it as CMS. This should read "CRM." The article's references are correct.) Good News for PHPersOct 9, 2007
It just warms my heart to hear of technology platforms opening up to one another, and the news due to come out of ZendCon is some serious warming. Today, there is an ever-decreasing pool of arguments against PHP in the enterprise. Between suites of tools like those from Zend, a variety of different frameworks and development tools (including the relatively new Zend Framework), and the near perfect ubiquity of PHP availability, this singular programming language really has staying power. Some of the latest news is just reinforcing that.The big news is all about PHP & Microsoft playing nice. Very nice. PHP developers who are stuck on Windows platforms (I've been there myself, it's not fun) will soon be getting a native FastCGI module for Windows IIS. Previously, we had one built by Zend, but it wasn't ever really as good as what Microsoft could come up with (since they know their systems the best). This will mean PHP will run more efficiently and generally faster when being used on IIS (Apache on Windows folks, you'll still have Zend's FastCGI module for Apache on Windows ... though I doubt your sanity in some other respects). This is great news, but wait - there's more! For anyone who's ever really been stuck in a Microsoft infrastructure right down to having nothing but SQL Server for a database (again, I've been there), traditionally you're in a world of hurt. The best you've got is the ADODB class library, but even that can be pretty clunky. Hope is on the horizon, though, because Microsoft and Zend have built a native PHP extension for SQLServer! Finally we will have the capacity to access our SQLServer-stored data in the same easy to use optimized fashion as MySQL, DB2, Oracle, and others! It's almost good enough news to make me want to go back to a Windows infrastructure ... but not quite. For Microsoft's part, they'll have their CardSpace mechanism integrated with the new Zend Framework. I don't really know what's that worth; in fact, I hadn't even heard of CardSpace until I read this article. From what I gather, it's basically the same idea as OpenID, but closed-source, .NET-oriented and Windows only. Fine, we'll integrate it, but that doesn't mean we have to use it (if anyone ever finds a PHP-powered site using CardSpace, let me know). In non-Microsoft news, the PHP Development Tools extension for Eclipse is growing up and will soon be the Zend Studio for Eclipse. I can only assume this will be open source like its predecessor, and it will include a bunch of goodies for pro-types: "What we're doing with Zend Studio for Eclipse is providing support for the whole lifecycle, which includes things like re-factoring, unit testing, profiling and integration with the Zend Framework," Gutmans said. "We're going to include everything that a professional PHP developer needs."So all around, some pretty good news. Our Windows-burdened brothers will soon have the tools to make their lives very much easier, and us Eclipse-using folks will soon have some pretty great professional tools from Zend. Beta TestingSep 27, 2007
Have you seen the new look for amazon.com ? It's actually kind of snazzy. I haven't had a chance to dive deep into its usability/architecture/etc but on the surface, I think its pretty (though a bit retro in terms of design). Here's a small screenshot (click to open): Of course if you haven't seen it, don't feel bad (or dumb). It would appear that the new look does not appear for everyone all the time. I first heard about it early last week, but when I went to buy a book, I just saw the rather half-assed redesign they did a while back (the one that condensed 82 tabs to three). I figured "meh" and went on with my day. Then I got to see this design (on my iPhone, no less, just before I found the new iPhone-version of Amazon) and was impressed! When I pulled it up at home to show Z, it was back to the icky version again - making me look crazy(er). What gives? Turns out Amazon appears to be running a particular type of beta test in which not everyone will see the new design all the time. Maybe its tied to particular user groups, particular locations from which the site is accessed, or certain Amazon servers having one design while others have hte old one. Not sure, but at least I'm not crazy. Which has brought me to think about how companies run beta tests in the modern day and age. The beta test is software speak for letting people use a piece of software (or website) before it is officially ready. Beta testers know that the software isn't officially "released" and will probably have some bugs. The tests are great for software developers who tend to have myopia and therefore cannot see bugs in the code, user work flow, or user expectations and experience. Think of beta tests as a focus group research. You've probably beta tested stuff yourself; "beta" websites are all over the web these days - some of them never leave beta (Gmail, for example, is still technically a beta product). There are quite a few different ways to test a web or software product before it's released - some of them are good, intelligent methods. Others take users by surprise, rattle their cages, and then return them to their previous lives shell-shocked and feeling a mite violated. To review, here are the goods and the bads of beta test methodologies (some of them, anyway): The Deliberate Focus Group During design phases, a development group with enough time and resources (or a lot to lose), will go through focus group testing as part of their design phase. The architects write out a bunch of ideas, then ask people who represent the eventual users what they think. Then the designers build out wireframes and basic designs or functionally representative mock-ups, and then ask more people who represent the eventual users what they think. This feedback loop continues for a little while (depending on resources) until ultimately the official alpha and beta tests where larger groups of people try things out for a while, give feedback, and test some more. Though when a company has enough at stake to run this kind of focus group, the beta testers are usually technical experts themselves, so the real effect is dubious. By the time the app gets in the hands of real users, no major effective changes would ever really be made to the software. It's a slow process and not keen on rapid application development, where changes are made hard and fast. Example? I would think major softwares like Windows, Office, and OS X use this method, and I know that salesforce.com does. The Open All-Site All-The-Time Beta Without considering the design phase, the open beta is when a site or a service launches, but launches with the caveat that it could all change at any given moment, that the databases could blow up and all that user data goes away, or that the site could crash forever at anytime. The site is free and open to everyone, but the word "Beta" typically appears prominently in the logo (if its not the logo itself). The builders may also not entirely be sure what the heck they're doing. But it's a chance for everyone to test out a new service and for the company builds mind and market share while determining strategy on the go. Most everything from Google starts out this way, as does just about every other "Web 2.0 business" out there (except for the closed beta ones). It's a fine idea for mass consumption and buzz-making, but it can also backfire a tad. Betas are not meant to be permanent but some services (Gmail!) never. ever. leave. beta. And that's when it just kind of becomes a joke. The Closed Beta (or "Private Launches") Closed betas are when companies have a product or site but they only open it up to a select few people. Those people may be thought leaders, the press, friends & family, technical gurus, or whatever, but the fact is, you're not invited (unless you ask to be, and even then, you're probably not). My problem with closed betas is that they don't go about it well. The owners typically try to use a closed beta as a marketing ploy, a buzz-maker, or some such tool to build anticipation. They market and show off their service to the blogs or the press, who then talk about the service as desired. Of course when one goes to check it out, they're confronted with the "Closed Beta" screen and a box to subscribe to updates when (if!) the service ever launches. Fav.or.it is doing this (tsk, tsk, Nick) as is a number of the firms debuting recently at TechCrunch40 and DEMO. But what's the point? I go to these sites, they don't let me in, so I don't care about them. If you're going to do a closed beta, don't tell anyone about it. Just invite your testers, refine your code, and don't start the marketing engine until it's actually effective and people can actually respond with a verifiable action. You're not Apple, after all. Parallel Roll Outs Of all the beta roll out styles I've seen or worked with, I think Parallel Roll Outs are the smartest way. This method is when a company builds a redesign or upgrade of their site, and then launches it separately from the main site. They invite users to try out the new site that's coming, give feedback, and grow accustomed to the future. After doing quite a few redesigns and consumer-facing roll outs for big media sites, it's become ever more clear that users hate change. When ABCNews.com relaunched their site with a fresh look, new video focus and nice community features, there was a lot of backlash from users who "hate hate hate" the new design. It happens. The best way to ease users into it is to let them opt in ahead of time, grow accustomed, give feedback (or vent), and just get used to it because there's nothing they can really do about it. But at least they feel like they have a choice. This method can be a pain for producers, since it means supporting two live sites, but it's the best method for keeping as many users as possible happy. CNN, YouTube, Comcast.net, even Yahoo has used this method whenever they launch major overhauls to their web properties. The Unbeknownst Focus Group Finally, there's the unbeknownst focus group method. This is when a company or service randomly rolls out new features or designs to a select group of people. Usually what's happening is the company is performing various tests in the background to see if users are able to perform basic functions, or if a particular button in a particular layout has a more successful click-through rate than another design. Google does this quite often with their search results; and this is what Amazon is doing right now with their phased roll out. Used effectively (and in small scales ... like Google's search results) it can be a wealth of information for the company's designers. Used poorly, like Amazon, and it's just confusing. If I don't get to choose to use a new design, at least be consistent. Bouncing from one look and feel to another not only confuses a user, but they don't like to look stupid when they say "Hey, it's a new Amazon!" when all their friends see the old Amazon. Beta tests are really useful tools and a great way to reduce the friction one inevitably gets from customers ... when they're used effectively. Of course, if the developers are thinking myopically about their own test parameters, rather than thinking about what the users are going to think and experience, it can be a pretty bad experience for all. Amazon gets a thumbs-down for their haphazard testing ... but at least its pretty. How Not To Handle Bad Press In The Modern Internet EraSep 25, 2007
A couple of years ago I attended BlogOn -- a social media conference where for a couple of days a bunch of tech heads, forward thinkers, theorists and those who want to be them talked got together to discuss the business of blogging and social media. One story I was particularly impressed with came from a customer service higher-up from Sprint. As a mobile service provider they rarely get much love, and in a couple of particularly places this customer service higher-up decided she would engage those dissatisfied with Sprint's service.Visiting the blogs and forums in question, this particular exec responded -- publicly -- in the blog comments and offered to continue to discuss remedies to the situation, eventually working out an amiable resolution. In addition to resolving a customer problem, Sprint did a number for its image among that particular audience, including many, I'm sure, who were not Sprint customers. Obviously it would be difficult (and a total paradigm shift) for a business to do this constantly for every bad press they find, but the idea is there to listen to and talk with your customers in the places they talk about you; it's a marketers dream and dreamland is the blogosphere. Fast forward to today to witness a company who did not attend that particular conference, apparently. Video Professor, a purveyor of educational CDs by mail (a rather silly business model in today's age but that's another post), has decided to sue 100 people who posted negative reviews of its product online. The company's lawsuit claims that the griping posters violated federal trademark laws by saying negative things about the company, and committed defamation and several violations of state law. After filing suit, the company sent subpoenas to the operator of the websites, demanding the release of the posters' identifying information and the IP addresses from which they made the posts.Well, if you can't take the heat ... I highly doubt it's trademark infringement. Otherwise, what happens if Consumer Reports does a negative review? Or the first news reports on possible lead-paint coated toys before? If we can't talk about our negative experiences with a company, then there's no trust, no quality information, and no way to actually make an informed decision (something VP's own site invites you to do). But legal fallacy aside, what a stupid way to do business! In the modern Internet era, the fact is that people talk online. They've always talked and shared they're negative experiences with others. The difference is that now we all know about it. It's a good thing, really, as information is meant to be shared, open, and universal. Of course, that goes both ways. These are facts of life, and businesses have to realize that it's going to happen. Period. Negative "press" is a tough to swallow and tougher, I would bet, if its legitimate. But the age of company PR trying to forcibly stifle bad press is gone, especially online. Information is running naked down the field; trying to trap it is only going to give it energy. What Video Professor should be doing is engaging the negative criticism. Internally, they should obviously be examining their processes to see where things are going wrong to create such a negative customer experience. Externally, they need to embrace the conversation, talk with their customers, confront the bad press. Internet-oriented consumers are the type of people who personalize their experiences with companies. They want to know the company is listening and when they feel it isn't, they turn to the Internet. Companies need to meet these customers where they are, respond in the mediums they float in, and use the same tools their customers are using to build loyalty both in their target audience and outsiders. Sprint did it (for a while). Video Professor ... well, not so much. Salesfore.com Can Make One Feel StupidSep 22, 2007
Just a couple years ago, I was part of a major software acquisition/construction/deployment project for the staffing firm I worked for. The software was for tracking sales, applicants, and billing - in short it was People-Software or Customer Relationship Management (CRM) software. If you've ever worked with or tried to build CRM software, then you have a pretty good idea how painful it can be. For users, it never does quite what you want it to. For administrators, the use-case branches are endless. We got the damned thing deployed, mostly, but development continues to this day. Boy, were we stupid.I just got back from the salesforce.com DreamForce conference this week. My company was exhibiting our ability to integrate market data with Salesforce for financial advisors, analysts, etc who wanted market prices seamlessly built into the application. Kinda fun stuff to play with. But the latest announcements, and the samples of what other big firms are actually building on Salesforce, amazed me. For starters, a 30,000 foot view. Salesforce is CRM software originally intended for - get this - sales people. With this online ("on demand") service, sales teams can keep track and get access to their accounts, contacts, leads, opportunites, and closed deals from anywhere. Sales managers could keep their staff accountable, executives could see what was exactly in the pipeline. From there, the company added features for marketing folks for tracking campaigns and measuring ROI (as campaigns lead to new accounts for sales people, etc). Then companies could track support issues with their accounts in the Service & Support edition. Even with these and other expansions, though, obviously salesforce.com could not build editions for every conceivable business process, and even if they did, most companies have idiosyncratic ways of doing things that wouldn't fit with the prescribed method. To fix this, salesforce.com allowed its customers and independent software developers to build anything they wanted on top of their platform - building custom "objects" or mashing together proprietary systems into the Salesforce interface. This ultimately led to the AppExchange where these applications could be shared and sold. Among the other announcements from the company, the two biggest and most important were the productization of the Platform as a Service, now known as Force.com, and the launch of their newest service - VisualForce: User Interface as a Service. What's the big deal? Well for starters, any time one needs to build software for an internal business process, they should seriously consider going with an on-demand process like Force.com. Using on demand services eliminates the need to support datacenters, databases, backups, security concerns and capacity all by oneself - salesforce.com is doing that themselves and letting you ride their coattails and only paying for what you use. In addition to the dramatic cost reductions this obviously brings, the time involved in building the software is a fraction of the traditional model. By way of an example, Electronic Arts and Disney both talked about their uses of Force.com an in one case, it took Microsoft developers 3,000 hours to do what Salesforce could do in 90 or so. One of the biggest problems to date with on-demand services, however, is that often certain elements are trapped into the vendor's way of thinking or behaving. This is a necessary evil, really, as in order to provide the greatest possible benefit to the greatest number of clients, some of the more picky perfectionists have to deal with prescribed ways of working. In particular, to date we've been stuck with the user interface rules of Salesforce, and the one-object one-screen rule. With VisualForce, however, salesforce.com is letting us change that. Now, we can build any application we want, on demand, and make it look like however we need, on any device from PC's to tablets to iPhones. The implications are major - aside from the persnickety brand-conscious maniacs like myself who want it to look just so, firms can eliminate the pieces their users, partners, vendors, and call center staff don't need. Combined with Apex Code, Visual Force allows for exact work flows, dummy-proof interfaces and brand-perfect look and feels. Throughout the whole conference, all I could think about was that recruiting application we deployed. How stupid we were - how entrenched in classic client/server software thought that we didn't see the value and cost savings of on-demand software. Sure we had some unique integrations to take care of, but nothing that simple web services wouldn't have solved. At the time we were so concerned with keeping our data in silos and owning everything we could that the expenditure was enormous. If we had just talked to salesforce.com, things could have been very different, and our lives a lot easier. Of course, Salesforce was nothing like it is now, but the possibility was there. Today, there is no excuse for not considering an on-demand solution like Salesforce when implementing any business-process solution. On-demand services have been quietly invading our lives for years. Google is purely on-demand; whether its Mail, Calendar, Docs, Picasa, or any of the others, the stuff I want is there when I need it, wherever I need it, and with Google Apps I can brand it for myself, even. Combine the Google APIs with Salesforce and Facebook and XMPP and LinkedIn and Plaxo and you've suddenly got yourself a business-operations toolkit without spending hardly the cost of the laptop you're running it from. All I can say is the possibilities are still making my head spin just a bit. My contacts at salesforce.com laugh at me just a little when they hear me evangelize the software as much or more than their own sales engineers - but all I can say is that Salesforce will be the first place I evaluate whenever I need to put in new software someplace. iAppsSep 21, 2007
Lost in the shuffle of the new iPod Touch and the iPhone pricing fiasco was a subtle realization that is just now hitting developers, designers, marketers and web professionals. These suckers have a full-featured browser and an interface like none other; more than that, they are taking and will continue to take the market by storm. The growing ubiquity of WiFi (combined with the Edge network for iPhones) will mean more and more people logging on from these suckers for any bits of data, information, or entertainment they can think of.While developers generally luck out with the fact Mobile Safari can view almost any standard website without any trouble,1 the constant need to pinch, pull and flick large sites can get tiring. Designing for Mobile Safari results in more user-friendly applications as clearly evidenced by the likes of Facebook (mobile) and iPhone18. Of course, building a proper application for Mobile Safari will take a bit of skill. The interface is different (fingers are bigger and clumsier than mice), the infrastructure & environment is different (integration to a phone (but only for iPhone), no Flash but native playback for video), one has to expect slow networks so caution is required for large pages or data sets; but these are small hurdles compared to the customer loyalty built by having a Mobile Safari-friendly application that's easy and fun to use. Categorically, marks of a good webmaster have been his/her understanding of MVC, separation of form & function, usability, accessibility, and information architecture. Generally, lack of mobile support has been forgiven and easily blamed on the devices. Now, that's becoming less of an excuse, and the standard is being raised. Support any modern browser, make it user-friendly, and make it mobile. More: A List Apart has a two part article on Web Design for iPhone (part 1 | part 2) 1) Out of the hundreds and soon thousands of sites I visit on my iPhone only two have not worked. One of those was a poorly designed all-Flash site (tsk tsk!). The other was ZipCar, strangely enough, but this week ZipCar launched a mobile (if not iPhone-specific) version of their site. Jakob Nielsen, Eat Your Heart OutSep 21, 2007
As a few have heard during one of my spirits-filled pithy Theory-Of-The-Web rants, I'm not really a fan of usability expert, Jakob Nielsen, despite the 50% (and decreasing) of his writings that are actually worth reading. Among his many soap boxes is the one about links: Don't Say "Click Here." It has no inherent meaning, interrupts flow, and doesn't allow for persuasive navigation (i.e. the linked words "click here" don't tell me anything about what the next page has in store). Some recent user tests are turning this Internet-age-old wisdom on its head, though:"From a copywriting standpoint, it's a no brainer--it's been proven time and time again that if you want someone to do something, you'll get better results if you tell them exactly what to do. ... The goal was to find out if the wording used in hyperlinks could make a difference in clickthrough rates. The answer is yes. They found that the right two or three click link words can lift clickthrough rates by more than 8%.When, and how, to link is an art more than a science (even if its an art only us theorists and certain perfectionist copywriters care about). Surely there is wisdom in avoiding gratuitous use of "click here," but from a marketer's point of view as in the study above, users are stupid and need to be corralled. At the same time, among blogs and more academic writers, the in-context link has replaced the use of footnotes to cite references, as the blog citing the study above does. This is good from a general usability point of view since you can guess what the link is about from the context of the paragraph (it's also good for search engine ranking). However, it is also often used to a fault as the author links way too much text, or as many do, will link several individual words to cite multiple sources. In-context links can be useful, but they sure can get annoying. Ultimately it depends on the purpose of the link. If the purpose is reference, use contextual clues. If it's actionable and measurable (for marketing, sales, etc), the be more forthright with the user. Google's CEO is Confused About the WebAug 22, 2007
So I found this little video in my blogroll a couple days ago, and finally got around to watching it. I expected some great insight into the future of the Web from none other than the king of the Web's king - Eric Schmidt, CEO of Google. Wow, was I disappointed! I think the event was yet-another Web 2.0 conference where a bunch of thinkers and the press get together to applaud themselves on being forward thinking webheads (I've been to these things - it's all cyclically masturbatory). Anyway, the question was "Today we have Web 2.0 - what do you think Web 3.0 will look like?"Now, I've come to understand that, for the most part, these days there is a dichotomy between the people who lead technology businesses (or business units) and the people who actually lead in technology. Some of this may be the fact that those who are leaders in technology actually love what they do and don't want to manage or simply don't have the business skills to manage. I'm not sure if this trend will ever go away, annoying as it is; but if you are the business head of a gigantic technology organization, you either need to be educated well enough about the technology (and not just the business of technology) or shut up about things you don't know. Mr. Schmidt, I'm sure, is an excellent manager of the business of technology. Surely he brings a level-headed sense of numbers to an otherwise haphazard, crazy-idea, Beta release-driven company (as evidenced by recent pull backs in product roadmaps and a strong focus on finding ways to monetize their proudcts beyond just AdWords). However, he has betrayed himself as obviously not being the technical genius of the group - when he barely realizes that while Web 2.0 may be a marketing term, the nature of what he describes Web 3.0 - the future! - is already in existence today. Here's the clip, and my thoughts: He makes the following points: Web 2.0 is a marketing term ... Up until now, Web 2.0 has been a term that corresponds to something called Ajax. Ajax is a computer architecture that's the underlying architecture I'm talking about. I'll give you that one, since it was kind of a term made up by Tim O'Reilly to describe a trend that was appearing on the Web. The O'Reilly camp went on to write books and magazines (taking over the prestigious (and pricey!) Release 2.0 rag) and articles and more books and give speeches and so forth that really propelled a lot of chatter and new development concepts online. But the fact is, the term was merely an attempt to classify something that was already happening - and that something was much more than just Ajax. Ajax is more of a marketing term than Web 2.0 is, in my opinion, because everything that makes "Ajax applications" so neat and cool have been around for a long time. The glitz and glamour used to be called DHTML (it just didn't have that freshly-scrubbed ring to it). The guts of asynchronous data retrieval that powers modern Ajax apps was around and was being used by Microsoft to power Outlook Web Access for a long time. Obviously XML has been around - its just that we're finally able to make it good for something. Web 2.0 describes the fact that the technologies and attitudes of the technologists have finally converged to allow for new applications that do things the old, silo-oriented, bubble-tastic Web 1.0 couldn't do. By the way, you know a person is feeling the heat when he actually mumbles out something like "Ajax is a computer architecture that's the underlying architecture I'm talking about," ... huh? My prediction is that Web 3.0 will be seen as You mean like Mash-ups? Mash-ups are here now, Eric. In fact, your engineers at Google have been opening up your architecture to allow for mash-ups for years. It's one of key pillars of your product strategy for Maps! Mash-ups may continue into Web 3.0, but they won't be revolutionary - they'll be standardized (and hopefully monetized). + applications that are relatively small Relative to what? Relative to traditional deployed software like Microsoft Word? Yeah, of course. Already the standard development cycle online is extraordinarily accelerated - we live and die by rapid application development. Whereas it takes years for the old names to release a new version, Salesforce.com releases four new versions a year. + the data is in the cloud Yeah that's kind of like mashups - but it's a bit obvious here he's regurgitating a sound byte he heard from Sergey and Larry. The idea that in Web 3.0 will be able to pull information from the web without lots of nasty parsing, APIs, and manually opening architectures is a kernel of what's been called the Semantic Web - the closest archetype to Web 3.0 the web groupthink has come up with. I would like to note, as well, that I think Google is very much working on this already. The changes over the last couple years in the way their core search product works has hinted that Sergey and Larry lean towards the belief in the Semantic Web idea and that Google can lead us there. + the applications can run on any device - PC or Mobile phone Say Hello to iPhone, Eric, I know you have one. The hindrances of the mobile web have been device-oriented rather than web-oriented. And the architecture of the iPhone is setting a standard for mobile web development. Today, major websites (a la Facebook) are exploding with iPhone-friendly versions that are displayed automatically. And for all those that aren't enabled, the device can handle the Web. We're already here - mobile, device-independent web applications are a part of the Web we've got. Room for improvement? Of course! But we've got it now. [UPDATE: Two Days Later it's revealed that Google has had "a jump in mobile access to Google's services during May and June; a time when traffic usually drops off as users go on holiday." So even Google is all about the mobile - it has nothing to do with the future - it's now.] + the applications are very fast Buy FiOS and you'll get a fast application. But the current Web 2.0 world has been built for asynchronous data communication to limit full page loads and all the corresponding delays in data. + and they're very customizable Again - we're already here throughout the web! Not in Google's apps, but elsewhere. + and furthermore, the applications are distributed by virus - literally by social network, by email, you won't go to the store and purchase them. I'll say to you, "Here's this interesting new way of doing one thing or another" Viral marketing is a neat concept, but its been done. A great number of companies have risen and crashed with viral marketing as their core distribution strategy. MeetUp, MySpace, Facebook, LinkedIn - social networks at their core, social distribution in their history. Seriously - even GMail had viral marketing as its core strategy in the beginning - when the only way to get a GMail address was to be invited by someone else who had one. These days, to have viral distribution as your only channel is considered an immature strategy, not genius. Le sigh. On he goes with describing current architecture, current distribution and marketing strategies, and current application requirements all of which have nothing to do with what the next-big-thing will be on the Web. What really betrays him is the comparison in the end: + that's a very different application model than we've ever seen in computing - very different from the mainframe era, very different from the PC Industry, much likely to be very, very large. There's low barriers to entry - there's a new generation of tools being announced today - Google and other companies make it very easy to do, solves a lot of problems and works everywhere. The mainframe era, Eric? Really? I can't really fault him for not really knowing what the future. He is, after all, a business man, not a theorist. The genius that runs the company is different from the genius that built it (and continues to build it). He's a good manager, a great spokesman and public face for the company, but it's unfair of reporters and sycophants to assume that just because he runs Google that he's prescient about where the Web will be. Google is a business, not a religion. If you want to know what the future of the web holds, get out there and start dreaming it up. *Of course, now my chances of getting a job at Google are blown to bits, but hey, I just couldn't let this one go. :) Developing For the iPhoneAug 20, 2007
So Steve Jobs may not want anyone building native applications for his precious iPhone platform (yet), and may be trying to blame that on the shoddy AT&T network (which, despite AT&T's objections, could actually be true), they do have a pretty nice developer's guide for building web applications that will work with the iPhone version of Safari.There are a crapload of iPhone applications streaming out onto the Interweb. Many of them are just iPhone versions of pre-existing websites that are built to fit the content of the site into the itty bitty iPhone window. There's nothing really new going on there - we've been building stripped down versions of our sites for years. A lot of others are silly little games or haphazard mashups that really add little value. But this morning I found an app that is really very nice, and is a great demonstration of how to build a totally different kind of web application. It's called iPhone18 and is basically a golf scorecard for your iPhone. What impresses me about this application is that it works more like a native application than it does a web application. For a web application - like Facebook for iPhone - when you click something, the page sits, loads, and appears. On iPhone18, the interface scrolls to one side. Gentle, fluid movements are what makes iPhone applications beautiful - and iPhone18 does a great job replicating that. Other key things to remember are that buttons need to be big, data display simplified, and all your screens of data are essentially task-oriented islands of information. Lastly, the application should take into account the fact that the iPhone browser rotates its orientation to tall or wide depending on how the device is being held - so the application should be fluid. These are just preliminary observations, because right now I'm anxious to get home and develop something really cool for my iPhone. Random Thoughts on Web 2.0Jul 29, 2007
A major tenet of the Web 2.0 movement is that Internet is a platform, with many different data sources mishmashable and cross-referencable. Some proponents want us to believe the desktop will soon be useless as our most common functions - from word processing & spreadsheets to (soon) a lightweight photoshop - become available online and in many ways, are more reliable. I have my doubts - and my doubts are increasingly being confirmed by the advent of new technologies that are bringing web tech back to the desktop. Adobe Codename Apollo lets us take our Flash and Ajax applications and turn them into cross-platform executables. .NET 3.0 and WPF is giving single-minded Windows-only developers a rich toolkit for interactive desktop applications. Moreover, the browser was never really meant to do what we make it do, and bandwidth considerations limit the real possibilities of distributed applications. Generally these days, I'm more interested in what I can do on the desktop than on web applications. In part, I'm figuring there is a happy medium. Internet applications give our data ubiquity, more stable backups than our own coffee-susceptible notebooks, and open the data up to mash-ups and expanded uses. Desktop applications come with us when we can't get or don't want to pay out the nose for network connections. They are faster, less susceptible to bandwidth issues, and not contained in an annoying, security-sandboxed window. But if we reach the point where the desktop is nothing more than a pretty container for our web-powered remote-data-storing apps, does that have ramifications for the personal computer market? If the application is essentially stateless to the desktop environment, and all the good stuff is stored, processed, and otherwise accessible online, then what's the point of the desktop war? What's the point of paying $2000 for the newest MacBook if its bascially a dumb terminal? But of course this all conjecture as long as we have to sit within 200 feet of an access point or find an Ethernet port. We need ubiquitous, gigabit networks in order to get anywhere close to the perfect hybrid desktop/web 2.0 world. It's So Hard to Find Good HelpJul 20, 2007
So in my daily job we are going through a hiring phase, trying to get some good fresh talent on board and share the load my colleagues and I have been bearing (with a smile). I always forget how hard the hiring process is from the perspective of the interviewer. If only we didn't see the same trend in all our young recruits, I'd probably be happier with it. Sure, some of them overstate qualifications on their resume, but these are quickly rooted out in the skills assessment and they never get to me. (Hint: After 5 hours on what has been benchmarked at 30 minutes, just give up.) Others have absolutely no clue what they want from a job or why they're even on the job market. These I can deal with too. My problem is the ones who get to my layer of the interview, and are nothing more than programmers. I don't ever put a recommendation through on a programmer, I always want to hire developers. And the key difference between the two is not what they're capable of with a keyboard, its what they're capable of with a pen. Can you think creatively? Are you aware of the world around you? Do you even know what's happening in the web industry? All of these questions would be simply addressed if our candidates read anything close to a recent journal. It could be a tech website, it could be TechCrunch or ArsTechnica or even Slashdot. It could be a set of blogs or Wired or even the Technology section of the New York Times. But the number one disqualifier of candidates for me is when its painfully obvious they don't read. Because when they don't read, they can't tell me a lick about Web 2.0, Ajax, Flex/Flash, the marketplace for Vista, Widgets, RIA development, or any number of other crucial trends in the marketplace that developers must know about. And that's when they get shown the door. The Curse of PrePackaged SoftwareJul 11, 2007
So one of my current client (freelance) projects is to essentially rebuild his site using the same base software, but essentially do it right where his previous half-baked developers didn't, or where they had no choice but to do it wrong. The software in question? vBulletin. This Great Britain-built PHP-based software, now in version 3.5 is a very common and robust platform for social sites that involve some measure of community or discussion boards. As a piece of software meant for the common, non-technical site administrator with a dream, its decent. It's dummy proof from the users' perspective, and the development team has built a lot of really interesting programmatic tricks to make it do what it does. Of course, these programmatic tricks create a problem for other developers who need to expand the base system. Developers like me, with clients like mine who have creative brains and big goals. And it isn't even that the twists and turns built into the system are terribly obscure or bad coding, actually its all pretty good coding. The problem? Bad documentation. And when I say bad, I mean nonexistent. You see the vBulletin team in its greater wisdom has built an extensive system of pluggable hooks - in which hackers like yours truly can insert their own code which the software executes as if it were its own. Its a genius approach, really, and allows me to develop plugins without touching a shred of the core code (a primary requirement for this project), so the core can be upgraded without breaking the site. But there's very little to no documentation for the plug in system, and it becomes very clear very quickly on the community site and throughout whatever little documentation there is that the vBulletin team put the hooks in by user demand, but they really don't want anyone to use them. In short, my preliminary problems with this software, from a developer's perspective, include:
|
|||
