Very similar to last year, the fun started with the pre-party in The Fountain Head, a pub that has been chosen as the port of call for most dConstructers. Before I knew it I was discussing techie things with people. Of course I had to ask the Magento question then and there. Answer was: people knew it, found it too complicated, outsourced it to others :) This shouldn’t have surprised me really – after all, this wasn’t an ecommerce conference, and people were mostly doing frontend development and working with CMS systems such as Expression Engine and Drupal. But let’s skip the pre-conference fun (there must be plenty of traces of those in Fourquare, Gowalla and Twitter anyway) and dive into Friday’s sessions.

Part 1

The first speaker on the bill was Marty Neumeier, who talked about The Designful Company. He suggested a very broad definition of design (something like “something that is being done to change the status quo into a more desirable state”) and argued that companies needed to aim at creating a brand that is both good and different to survive in today’s marketplace. In my opinion, I couldn’t follow Neumeier’s application of design to what seemed brand development to me, so I didn’t find this first talk to be very insightful.

The second speaker was Brendan Dawes, who in his Boil, Simmer, Reduce-presentation talked about the creative process of first of all collecting ideas and inspiration (he claimed the iPhone and a notebook to be his collection devices for this purpose), then to reflect everything for a while and finally reduce the output as much as possible to get the best result. This three-step process happens more or less unconsciously and is true not only for design but for all creative work such as making music, writing texts etc. Thus, the message wasn’t new, but the presentation itself was quite vivid.

Next, David McCandless talked about how Information is beautiful. Using numerous examples of seemingly uninteresting and unrelated pieces of data that have been visualised and ‘designed’ as it were, he showed how new insights and relationships can be gathered from this procedure. I was mostly impressed by an infographic which showed media coverage about panic regarding diseases such as SARS and all kinds of flu epidemics; at the time of 9/11, there was a big empty gap in this timeline.

The first really hands-on presentation, in my opinion, was offered by Samantha Warren who quite enthusiastically talked about The Power & Beauty of Typography. For me as a non-designer she had a very interesting take on what a fonttype can do for a website: a font can be seen as a kind of shoe that either fits or doesn’t fit the occasion -  each font/shoe tells us something about the person that is using/wearing it.

Part 2

After that it was time for a lunch break. It could have either been the lovely (pebbly) beach, the great fish and chips, the nice weather or a combination of all of these, but I unfortunately missed most of John Gruber‘s talk on The Auteur Theory of Design, so I cannot say anything about it here.

This presentation was followed by Hannah Donovan who spoke about what Improvisation can teach us about design. Before her actual talk, she performed a short and improvised musical piece with two colleagues. Then, she described how improvisation is used in music and music education and how a framework is necessary to provide musicians with the tools to be able to perform improvised music together with others. This conceptual framework and the respective tools are also the prerequisites for the design process, as she showed with the help of some examples.

Next in line was James Bridle who shared his views on The Value of Ruins. He focused on the idea that in order to shape our future we need to make sure not to lose sight of what happened in the past. He drew the audience’s attention to the archiving and loss of information in the past, a famous example of which is the destruction of the Library of Alexandria. In order to present a modern take on historiography, he showed us a printed version of the Wikipedia article on the Iraq War which consisted of more than 10,000 pages (as far as I remember) – a very impressive set of volumes!

As far as I’m concerned, the most engaging presentation was held by Tom Coates when he talked about Everything the network touches. This presentation mainly dealt with the web of data and the way in which these days we can connect countless APIs to create interesting and innovative services. Although the subject of this presentation was not revolutionary – actually, much of it reminded me of Alan Greenfield’s talk on Elements of a networked urbanism from last year’s dConstruct - it felt like a convincing and well-arranged summary.

Finally, Merlin Mann talked about Kerning, Orgasms & Those Goddamned Japanese Toothpicks. Without any slides he delivered his views on geek and nerds, why nerds should care about things and how nerds should stay nerds because somehow it would eventually pay off. To be honest, this talk did not impress me at all and felt like a half-funny nerd stand-up comedy.

People

In summary I can say that the actual conference didn’t impress me as much as the people I had the pleasure to meet in all kinds of pubs and restaurants. I would especially like to thank the guys from Zemanta (whose very useful service I’m using to produce this article and find interesting cross-references and additional information) for the great discussions of things digital and non-digital. See you soon!

Related articles by Zemanta

• dConstruct 2010: discomfort, irritation and reducing (onemanandhisblog.com)
• dConstruct 2010: Tom Coates on the sexy future (onemanandhisblog.com)
• dConstruct 2010: John Gruber on why your site needs an auteur (onemanandhisblog.com)

Native vs. web-based apps

There are more than 225,000 native apps on the Apple App Store right now, downloads have surpassed the 5 billion figure. With more than 100 million devices sold these apps can run on, they surely provide a ton of opportunity. Those apps have access to the entire hardware, ie. the respective APIs of the devices they run on, e.g. camera, gyrometer, GPS etc. Also, they can create push messages to the user, which is quite handy in case of apps such as Facebook and Twitter. Interface designers can get creative and invent all kinds of new uses, as for example the range of new games shows.
In order to create such a native app, developers need to make use of the SDK provided by Apple, obtain a developer’s license and start coding their applications using Objective-C and the Cocoa Interface builder. Afterwards, they need to follow a set of guidelines in order to get those apps into the App Store.

Web-based apps, on the other hand, don’t require this procedure. In effect, they are specially crafted websites which are accessed via the Safari web browser. Using the HTML5 standard, interface developers can create their code in such a way that they make a nice application in the mobile browser window. This means that, rather than seeing a minified version of the website in question – which is the standard – the mobile device renders this website differently, making it perfect for use with the iPhone or the iPad. A good example of those web-based apps is the mobile version of Facebook, which makes it possible to use the website properly even on a small screen such as the iPhone’s. (For more information on web-based vs. native apps, see Apps vs. Web by Craig Hockenberry.

Magento’s app generator

Having had a glimpse at the source code of Magento mobile it seems that it mainly does two things: First of all it provides the necessary interface for letting shop owners customise their own app and send its specifications to Magento Inc. They will have some sort of process in place that turns those specifications into a native app and place them into the App store. Secondly, it generates a sort of additional XML layer that feeds the app and provides all the necessary catalog data.

The second part of this extension, in my view, is the goodie because it provides XML-structured information regarding the shop frontend, which is the source for the native app’s more lightweight checkout process. However, the native app itself, which is the first part of this extension, seems questionable. Given that every Magento store owner could have one or more apps for his store(s), this would eventually lead to a flood of new apps that would only slightly differ regarding a few layout parameters. In other words, the code base for all those apps waiting to be submitted to the App store would be quite similar, which is something I think Apple wouldn’t approve of at all in the long run.

But even if a good amount of those apps made it through the approval process, I find it hard to imagine that potential customers would download all those apps. It might be that there are some larger and well-known brands whose fans will embrace such a possibility, but this is an exception to the rule. For a native app to be successful it needs to provide some added value for those who install it. But other than browsing the product catalog and checking out the respective products, those new Magento apps will add nothing new.

Far better suited for this kind of shopping experience are web-based apps. Why not provide a streamlined XML interface and let frontend developers come up with a great mobile version? The iPhone theme, which was published in 2008 already was a step into the right direction, and I think in the long term store owners are better off concentrating on universal, platform-independent web apps than native apps for each and every platform.

Yet another distinction?

Before reading the piece, I haven’t put much though into distinguishing between the words Web and Internet. In Anderson’s sense, Internet is the umbrella term for every bit of hard- and software that forms the global information network all of us spend a great deal of their time with. Web, on the other hand, refers to the world of browser-based, http-port80-style access of HTML pages. Following this logic, the Wired.com website belongs to the Web, however, the Wired iPad app does not; yet, both are parts of the Internet. Thus, the only reason to draw this distinction is to be able to terminologically locate the concept of Apps: They are different from the Web, but they still belong to the Internet.

Anderson’s argument is based on a diagram which allegedly supports his claim but actually only proves one thing, as BoingBoing has pointed out in Is the web really dead?: video generates a lot of traffic. Thanks for letting everybody know Mr. Anderson!

The bottom line

Apart from all the hype (after all, Wired is in the publishing business, who would complain about a little attention?) and the over-exaggeration, there is of course some truth to the story. Applications on mobile devices have a considerable impact on the way in which we interact with the online medium, there’s no doubt about that. Every time I use the Twitter app on my iPhone, I’m by definition not using the web interface by letting a browser decode the HTML of the Twitter website and present its information to me. The Twitter app makes use of machine-to-machine communication instead and pulls out all the necessary info out of the Twitter API.

A short history of mobile apps

One day before the iPhone was launched on July 11th, 2008, the Apple App Store came to live and is now the key factor for the success of Apple’s mobile devices, be it iPod, iPhone or the recent iPad. Each of these devices can directly connect to this app marketplace and download one of the more than 200,000 third-party apps that are on there. Within the two years of its existence, the App store has seen more than 5 billion app downloads to date.

Other manufacturers of mobile devices have started similar services in the past, as can be gathered from the List of digital distribution platforms for mobile devices on Wikipedia. According to this overview, the Android marketplace for example was launched in late October 2008, has about 105,000 apps and 1 billion downloads to date; RIM have started their App World in April 2009, featuring about 7,500 apps and about 1 million downloads per day.

In short: the possibility of increasing the capabilities of one’s mobile device by means of third-party apps exists for only about 2 years. In this short time-span, the app concept has proved to be a viable business model, which I will talk about in the next paragraph.

App economy

First of all, apps make users do what content providers love: they make them pay for content. A nice example of this is the Wired iPad app, which presents the magazine in a very modern, multi-media and, well, magazine-like environment. Rather than clicking through a website, readers can flick through the pages like they would with the paper counterpart. Or, as Anderson sees it:

Apps, for us, are just a way to put our best foot forward, to package text, images, video, interactivity in a designed package that can engage people for an hour, not a minute. It’s early days yet, but we’re already seeing an order of magnitude difference in iPad app session times compared to the same content on the Web.

Secondly, the degree of standardisation – one could also term it closedness – of the Apple app store for instance makes it easier for developers and publishers to forecast what the program output will look and behave like. In other words, there is no need to worry about different operating systems, web browsers or screen resolutions. Of course, opponents of Apple’s walled garden approach criticise exactly that: if functions aren’t allowed by the Apple SDK or the Apple approval guidelines, they don’t make their way into the App store. In my opinion, however, it does not take more than a short discussion with a modern webdesigner who has to fight with browser backward compatibility issues (just ask his or her opinion on the IE6 madness!) on an everyday basis to realise that the freedom the web offers sometimes is not the perfect solution. Users of Apple’s mobile devices are eager to keep their systems updated, so backward compatibility simply is not an issue here – making life yet easier for app developers.

Thirdly – and this ties in with the first point – app users are willing to pay for good applications that make their lifes easier or are just plain funny. And because app store accounts are tied to the customers’ payment data, the purchase process is as easy as it could be. On the web, there is still no generally accepted form of micropayment. In Apple’s app store, in contrast, the purchase of a 1$ app is just an uncomplicated click away.

What about the Web, then?

Of course the Web is thriving, the browser is the single-most important means of accessing its wealth of information. Even though it seems that everybody is using iPhones, iPads and Blackberrys and is always online thanks to mobile data flatrates these days, this is simply not the case. The majority of people are using their desktop PCs to access websites and their mobile phone to make calls. Period. Nonetheless, the app universe keeps growing and provides very interesting business opportunities. In some cases, apps simply do a way better job than HTML ever could.

Company + History

Magento started out as OS software provided by US company Varien, which got renamed to Magento Inc. just recently. After the first productive version (1.0) of Magento has been released in March of 2008, Magento Inc. has decided to announce the (commercial) Enterprise Edition in April 2009, fitting it with more functionalities to cater for the needs of large-scale customers. An additional version, the Professional Edition, was introduced in May 2010. Magento Inc., as is stated on the company website, has been founded in 2001, has now more than 140 employees and is located in Los Angeles, California.

On the other side, the company OXID eSales AG exists since 2003 and produces its software OXID eShop on a commercial basis, selling both a Professional and an Enterprise Edition of their application. With version 4.0, which got released in October 2008, it was decided to also take a step towards OS and release the Community Edition under GPLv3. OXID eSales AG has about 60 employees and is mainly concentrating on business in Germany, Switzerland and Austria.

Installation

For this comparison, I had a look at the OS versions of OXID and Magento respectively.
After downloading the latest version of OXID CE (4.4.1) and unzipping the installation file, there are about 2,400 files, taking about 31 MB on my local disk. In comparison, the latest Magento CE (1.4.1.1) is more than 14,000 files strong and takes almost 100MB of disk space.
After installation – which is considerably faster with regard to OXID, but works smoothly in both cases due to the easy-to-use installer, OXID lives in 63 tables, whereas Magento needs a whopping 335 tables.

These differences in file and database complexity have their root in the different architectures of these systems, which I will come back to a little later on.

Code

One of the biggest problems Magento developers face these days is the fact that the Magento code is only poorly commented and a full documentation is missing. There are initiatives aiming at improving the Knowledgebase for example, and right now good progress is made because of the great articles written by Alan Storm. The reality of working with the Magento application, however, is that developers still need to find bits and pieces of information scattered across the web to effectively work on the programming tasks assigned to them. (A side note: the Magento community pages are a real pain to use!) With regard to code-quality, up until now there are no unit-tests in Magento (which mostly has to do with its architecture and the way in which all components are highly interconnected).

With OXID, it seems that this has been addressed from an early stage. There are unit-tests and the code coverage has now reached 93%. The results of this automated Selenium testing are published on a regular basis. Documentation, like with Magento, is not overwhelming either and can be found on the OxidForge website.

Backend

After logging into the admin panel, it becomes clear immediately that OXID follows a different usability strategy compared to Magento. Here, the main navigation is located on the left hand side of the screen, overview lists take up the upper half of the main content area, the details are worked on in a frame in the lower content area. Magento, on the other hand, follows a different approach, featuring a horizontal main navigation with dropdown-menus and overview lists taking up the whole of the content area.

It’s mostly up to personal taste which strategy is favoured – and in my opinion is not a killer-argument for one or the other system. Two things, however, are notable and seem to set the tone for each system’s strengths.

In Magento, you will find the omnipresent scope selector: this is the most visible proof of the fact that Magento is multi-store system. For each configuration – be it on system or product level – one can decide how far-reaching this should be. Is it a global setting? Does is apply to only certain websites or just a storeview?

With OXID, on the contrary, there is no such thing because the CE does not feature multi-store functionalities the way Magento does (I was told this is the case in the OXID EE). On the product pages there is a language selector enabling the administrator to enter different language versions for product titles, descriptions, etc. What caught my attention in OXID – and this is a major point of difference between the two systems – is the menu section entitled eCommerce Services. Here, the shop owner has access to a variety of interfaces such as affiliate, payment, price comparison engines. These are parts of the OXID eFire system, which is OXID’s hub for connecting the store software to all sorts of service providers relevant for the German market. eFire, it seems at first sight, is a very advanced and easy-to-use system that has no direct counterpart in Magento.

Products and attributes

Another Magento feature that is often quoted is the product types that can be used. Be it configurable products, bundles, product groups and even virtual and downloadable products, the software offers a wide array of possibilities for shop owners to choose from. OXID, on the other hand, seems much simpler in this regard. As far as I could see it, it is possible to enter simple products, add different product options and combine those simple products to form bundles that are put into the shopping cart automatically.

Magento’s architecture as well as its EAV database structure allows for complete flexibility with regard to attributes. For Magento, there are objects such as products, orders and customers etc. that one can attach attributes to – either on a programmtic level or via the admin panel in the case of product attributes. Those attributes can be of different types, so you will typically find price-, text- and number attributes.
In contrast, OXID is constructed in a simpler way and operates with flat tables. A product can be equipped with further attributes, however, those are simply full-text attributes which can be filled with whatever piece of information is necessary.

Magento’s flexibility in this regard comes with a price: performance. Governing a complex MySQL structure by means of PHP means that a lot of queries are necessary in order to deliver the necessary recordsets, for example if a product list should be rendered. In order to address this problem, Magento uses caching on various levels as well as (redundant) flat tables for example for the product data. OXID, due to its more lightweight architecture does not have these sorts of issues.

Frontend

One of the major differences between Magento and OXID is that there is no filtered navigation in the latter. After having marked certain attributes to be used as filterable attributes in Magento, the shop owner is able to let shop visitors further refine their searches. In OXID, this is not the case: here, one can either use the category or the result list without being offered futher filtering. Apart from this rather obvious difference, what the user sees on the surface regarding product selection and purchase is rather similar.

Underneath the surface, however, there is a world of difference regarding how the theming and frontend design are done in both systems. Magento relies on a complex system of blocks that are arranged by means of XML constructions and designed by a mixture of PHP and HTML. Furthermore, files relevant for graphical output are separated in server-readable and –not-readable parts (cf. /skin/-directory.) OXID, in the other hand, relies on the Smarty template engine and a special syntax in its .tpl files

Extensions

One of Magento’s most valuable – and most often cited – assets is its extension marketplace called MagentoConnect. Here shop owners can find more than 2,600 extensions, most of which are free or available at low prices. Thus, Magento’s functionality can be extended without much effort. The free community extensions can even be installed by copying/pasting the respective extension key into the MagentoConnect manager of the admin-panel, which then downloads the extension sources and installs them automatically.

OXID offers a similar system called OXID eXchange. Here, the user can choose between about 220 extension which are both non-commercial and commercial. Those extensions are downloaded as .zip-files and need to be uploaded/copied to the respective places in the OXID filesystem.

Costs

With regard to the license costs of their commercial editions – from what can be learned from the company websites – Magento and Oxid are also different. The Magento Professional Edition starts at about 3,000 USD a year, the Enterprise Edition license can be bought starting from about 13,000 USD/year. The OXID eShop Professional Edition 4 costs about 2,000 EUR (one-time fee), the Enterprise Edition 4 license can be bought for a 13,000 EUR one-time fee and follow-up fee of 4,000 EUR/year.

Tentative conclusion

Of course there is much more to talk about with regard to those two applications, and I hope this introductory post can contribute to the discussion of both systems. Both OXID and Magento have their individual strengths: For OXID, I would like to highlight its more lightweight architecture, the dedication to code quality and automated testing as well as the eFire platform. Magento’s strengths are the flexible attribute system (and on its basis the filtered navigation), the multi-store functionality and the MagentoConnect marketplace.

Goodsie, which is currently in closed beta, presents an intuitive interface. Without having to flick through a complex interface structure, one immediately finds his way through the menu items of the admin panel. The demo video the makers of Goodsie have produced shows how easy it is to set up a webstore, customise the layout and enter products:

Click here to view the embedded video.

In contrast to applications such as Magento, this application is a SAAS (software-as-a-service) solution only that can be rented for $20 a month. It relies on the payment methods Paypal, Google Checkout and Amazon Payments and a standard shipping method.

Of course one could say much about features that are not (yet?) implemented: there’s no templating system that would allow the shop owner to customise the HTML/CSS used to render the shop. There’s only a fixed set of product types which is used for entering products and there is no attribute system which would allow for more flexibility. Also, Goodsie misses import- and export functionalities, so products will have to be inserted one after the other.

Similary, the frontend is also very basic. Customers can view product details, have a look at categories or search for products. They add a product to the cart and pay via one of the payment providers mentioned above. No elaborate comparisons or upselling, not even customer accounts.

Not to be mistaken: This (apple-esk?) reduction of features is surely Goodsie’s biggest strength. For people just getting their hands wet with ecommerce or selling only a handful of products, this is without a doubt a great alternative. Without having to know anything about programming, one can easily set up a good-looking and easy-to-use store in no time.

Goodsie seems to have been the next logical step for Hii Dev Inc., who offer a similar product – Flavors.me – to build good-looking websites in a similarly easy way.

One thing is for sure: Magento has reached reality. Right now, agencies and developers around the world put this software to the test, building different-sized projects on the basis of the application. As the German blog shopanbieter.de (Magento stagniert auf hohem Niveau) has reported yesterday, the Google search volume for the keyword “magento” has been the same for the last 12 months, suggesting Magento has left its hype phase and stagnates on the same level. But to be sure: Now that the name Magento seems to be in everyone’s head, there is an increasing demand for professionals able to implement individual functionalities. This sounds like a technology goldrush, and in some respects it actually is. The problem is, however, that there are not enough developers who could satisfy this demand. When looking at the situation in Germany for example, agencies are desperately trying to hire new developers to build Magento-based stores. Especially with regard to Enterprise-level clients, the projects of whom require quite some effort, there are just not enough ressources.

Developers, developers, developers!

This puzzles me a little bit. Given that even a half-decent Magento developer can choose his employer these days and not only participate in interesting projects but also make good money, I wonder where the Magento offspring is. Is this because the application is just so complicated? Are people sceptical about this software after all? And how about neighboring communities such as the PHP- or the Zend-Framework people? From what I read, I cannot see anyone from those communities enthusiastically and wholeheartedly embrace the possibilies offered by Magento (I’m probably reading the wrong stuff). Is this software just not sexy enough maybe? I’m planning to do a little research and hopefully find an answer to the question why there simply aren’t enough Magento developers. (If you have any clue, please leave a message in the comments to this post.)

In my opinion, Magento – which is now the official name of the company behind the software – until now hasn’t put too much focus on alleviating this problem (apart from the recently introduced Magento Summer Webinar Series maybe). Apparently, there is a certification programme and I have heard about some developers in Germany who underwent a test that made them certified developers. These, however, seem to be rather exotic cases. I cannot find any information on the Magento site that would outline such a certification programm in detail. The official Magento Academy site, which is currently available in French only, offers training and certification. But regarding the latter, no much information can be gathered concerning what the certification process looks like, how much it costs etc. The way I see it, only a standardised certification process will lead to a professional environment where clients can adequately gauge the competence of partners offering Magento services.

Enterprise

A couple of months ago, Magento has raised about 22,5 million dollars from an unnamed investor. (The name of this investor has not been officially published. My guess: think about which payment provider got his own logo in the Magento admin panel at about the same time the deal was brought to the public.)

Another challenge looms in the Enterprise world. A couple of days ago Jochen Krisch from excitingcommerce.de has mentioned a rumour according to which Zalando, one of the flagship Magento Enterprise projects in Germany might be relaunched on the basis of the Hybris platform. If this proves to be correct, one can only speculate about the reasons. Is this also because there aren’t enough Magento ressources available? Or does it have to do with the fact that according to a recent presentation Zalando needs about 35 servers to be able to provide the necessary performance? Be that as it may, it’s clear to see that Magento’s credibility as an Enterprise-level application is at stake.

To some extent, this post leaves opens more questions than it actually answers, I will do my best to fill in the gaps in the next couple of days. If you have input/criticism for me, please fire away in the comments.

International eCommerce

The last six months have been an extraordinary experience. I got the chance to participate in relaunching some international brands on the basis of Magento by working as a project manager and a consultant. My daily routine involved numerous telephone conferences to get the different parties involved aligned, travelling and basically constantly juggling and processing of information. I had the feeling to be working on the forefront of development in the Magento world and to be doing meaningful work and helped shaping online stores that would eventually be seen by a lot of people around the globe. And I think I was.

However, as exciting as this challenge has been, it has clearly had some downsides which have led me to get out of this corporate ecommerce world in a rather unexpected manner. Suffice it to say that the everyday routine was not only a challenging with regard to time spent working (and not with family and friends), but also in view of physical health. After having been disconnected from the web for more than a month now I’m slowly getting back on track – getting my voice back.

This post and the relaunch of this blog does not only mean the new beginning of something that has been neglected for some time, but actually feels a bit like going back in time and continue where I have left off somewhere at the beginning of this year.

Magento

As one can imagine, I have spend quite a bit of time with this piece of software that has kind of ripped me out of my tranquil, doing-oscommerce-style-webshops-way-of-freelance-life in 2008. Ever since I came across Magento – one of the earlier posts was a longish rant on its poor performance – got asked to write a book on it (Online-Shops mit Magento (German), published by O’Reilly) I got to know the software closer, being able to provide training to those wanting to learn using it. In the last couple of weeks I have finalised the developer handbook for Magento (Magento – Das Handbuch für Entwickler) together with my pal Vinai Kopp and it’s planned to finally hit the shelves any day now.

I consider Magento a great application, however, having dealt with its nuts and bolts for quite a while now I can hardly only see things through rose-coloured glasses. Like with most other OS software out there, there are (annoying) issues which need to be addressed, both on the organisational and the technological level.

But there’s the rub: this blog (or rather its German predecessor) was originally planned to provide regular updates on recent developments in eCommerce – independent of software. Being part of the Magento scene (which I’m still very happy to be, no doubt about that), however, makes it harder to stay unbiased and take an objective view of the matter. I would like to take the opportunity and regain some of this pre-Magento independence and look at other software/concepts as well. For example, how does Oxid do in the OS world, which are the reasons why enterprises often opt for WebSphere and Demandware and how do new and lightweight systems such as Goodsie fit into the picture?

I’m looking forward to chasing the world of ecom again. And I invite everybody to have a read and add his/her opinion – it’s about different voices after all.

To avoid any misunderstanding: I am a big fan of all these streams of information and a firm believer of this kind of connectedness. Reading this week’s RSS backlog and Twitter timeline on a quiet and lazy Sunday afternoon, however, most of the things in there I find plain boring. Which makes you wonder: if something that I personally like to indulge in very much suddenly becomes next to irrelevant once the workload becomes higher, does this mean that the former is just plain old procrastination? Or is this just me having an info-phobic weekend and wanting to give this blog a bit of a rant? Be that as it may, I’ll keep exploring …

On the go: Calling and being called

Of course it is annoying not being able to pick up the phone, call another landline number and – thanks to our flatrate – talk for ages. However, since the people of our industry are often on the go, they are not able to access this connection anyway. For this reasons, more and more people seem to be shifting towards mobile flatrate plans so that they are able to make unlimited mobile calls without spending a fortune.

Similarly, getting phone calls to the landline number is problematic when one is miles away from his phone. Of course there is call forwarding, but in most cases, one is being charged for each call being directed to one’s mobile phone. Personally, I more and more tend to give out my mobile number so that callers do not have to take a detour via the landline.

Why making a call anyway?

Surely there are phone-calls that are really worthwhile: in order to clarifly a complex problem or ask a lot of questions, it’s so much easier being able to speak to one or more people involved. But in many cases, phone-calls are just useless and plain annoying. Here is my personal TOP3 list of grievances:

Getting calls by anonymous callers:
Communication usually isn’t a oneway-road. If you’d like to chat, please let me know who you are!

Getting “Call me back” voicemail messages:
It doesn’t hurt summarising the reason of your call in one or two sentences. If you’d like me to give you a call back, please give me at least a small chance to prepare!

Making me write down long texts during the call:
Why try dictating long sentences or URLs on the phone when sticking them into an email would be so much easier?

Up until now, Google first and foremost business has been in the realm of making money by shifting electrons: their most important asset  – paid advertising – is based purely on bringing together advertisers and potential customers. By means of an Adwords ad for instance, the latter are being forwarded to the retailer’s webstore and fulfill their purchases there. Google collects the fee for this click – business done.

The strategy behind marketing of the Nexus One changes this completely. With their plan of selling their phone directly from their own online store – rather than tying it to carriers, shipping it to their stores and letting customers experience it in real life – Google is offering an unlocked phone without any intermediary (in this regard, Ars Technica has published a piece on how Google’s latest move will affect the US wireless market). In other words, Google will start shipping real products and collect payments via – what else? – Google Checkout.

While surely being a well-equipped smartphone (detailed review by Techcrunch) it is by no means revolutionary; the real news is they way in which Google positions itself in the world of retailing and strenghtens its own checkout service.