My Perspective

Drupal Commerce

2010-11-17T08:52:00.000-08:00

I posted on Optaros website (EN | DE). Here is the copy of the post:

Drupal has always been good piece of open source software for content management. We use it at Optaros as one of the core components of OCentric. However, Drupal could never stand its ground as a solid e-commerce platform. With the new Commerce module Drupal is moving that direction.

Background

It hasn’t been long since online businesses realized that there are a couple of buzzwords to stick to: social media and SEO. Indeed, social sites are very good place to be and engage with (potential) customers, not mentioning that these sites enable word of mouth (aka viral marketing). Search engine optimization helps to save money and still allow showing up high in Web search results; normally it goes hand in hand with quality content to please not only Web crawlers but (potential) customers as well.

Actually, what this implies is that e-shop owners have very special needs that go something like this:

“I want to create a website where I want to display my products. There I’ll have discount campaigns. The information about them should be sent to customers, but not intrusively (otherwise it goes to spam) rather in a friendly fashion, e.g. somebody tells to friends about it. Then we can introduce some sort of reward system for those customers who brought other customers. Also we want people to come to our website often, therefore we’ll have a blog and a lot of information about products and the field in general. People should have their profile page and see what their friends are buying. We also expect that the shop is something like Amazon.com where you have ratings, comments, and recommendations.” And so on, and so on.

I come across similar business requirements very often. What it comes down to, as far as technology is concerned, is the following:

Shopping cart

Content management system

Social stuff (integration to social networks or local features)

In Optaros parlance it rounds up to the triple of Community, Content, and Commerce (aka C3C). In fact that’s what gave birth to OCentric.

Drupal 6.x and Ubercart

Drupal is a content management system that allows creating community oriented sites very easily. The last piece of the puzzle – commerce – for quite some time was the Ubercart module. I don’t understand why it got so popular. Even for the simplest shop there was something missing.

Ubercart is almost a framework on its own: you need to learn it and live with its limitations (or hacks). My overall impression about Ubercart is that it has many features you normally expect from an e-commerce platform, but as soon as you start working with it you realize that it is a big work around.

Ubercart’s approach is – sell nodes. A node (before Drupal 7.x) is a basic content type. Ubercart is implemented in a way that products are node types, but it’s very unnatural to treat a product as a content type. This is probably the biggest flaw of Ubercart’s architecture (not sure if this has been somehow addressed in Ubercart 3.x).

While in many cases Ubercart does the thing – you can sell stuff on your Drupal site – I stumbled on so many problems that I almost lost hope to have a cool e-shop with Drupal. Just to list a few:

It’s nearly impossible to customize the checkout page without hacking Ubercart’s core.

Internationalization doesn’t work, because in Drupal a new node is created as a translation, which means a new product gets created as well.

Presentation is not well decoupled from data model, therefore theming any part of frontend is very tedious.

Drupal 7.x and Commerce

Drupal 7.x introduced a lot of enhancements both for module and UX developers. The most famous one is the Field API. Having realized the benefits that Drupal 7.x brings Ryan Szrama, the creator of Ubercart, has launched the Drupal Commerce project.

Drupal Commerce is the reimplementation of Ubercart’s featureset on Drupal 7.x. It’s not a port of Ubercart 2.x but literally a reimplementation. You can see the video of Ryan presenting his work on the module at DrupalCon 2010 in Copenhagen.

The Commerce module heavily relies on native Drupal 7.x features, therefore there’s barely any risk that it will become a framework on its own. While Drupal 7.x remains a content management system, it allows for more generic entities than just content. For example, products, order, order line items can all be first class citizens in Drupal 7.x. Therefore the Commerce module is architected in a way that e-shop owners can sell products, without pretending that a node content type is a product. Moreover, the data model is decoupled from presentation, and multilingual shop is no longer an issue as it was in Ubercart.

What makes the Commerce module even more powerful and flexible is that it depends on several great modules (Address Field, Entity API, Rules, Views). For example, Views – almost everything visible in Drupal Commerce is a view. That means you can switch it on/off or customize easily. This is invaluable for checkout and shopping cart pages.

Summary

In version 7.x Drupal has become quite a generic framework, sort of entity management system, that has built-in content and community features. The Commerce module plugs in very nicely into this framework and solves a lot of issues of its predecessor Ubercart. Given that many businesses need to have content, community and commerce in one, Drupal 7.x may become an option as it matures.

DrupalCon, Copenhagen 2010. Impressions

2010-08-31T00:55:00.000-07:00

I won't hide, the most interesting and relevant session at DrupalCon for me was on Drupal Commerce. Ryan Szrama is doing amazing job with reingineering Ubercart, and I'm really happy to have been able to talk to him in person.

The reason why I'm interested in the Drupal Commerce module is that I worked on Magento and Drupal integration for OCentric at my previous company (Optaros) and I've seen how difficult it is to have content, community and commerce mix in one solution. Therefore Drupal 7 + Drupal Commerce mix looks really promising. Just think about having a piece of content and adding a "product field" to it, formatted with "Add to cart" button; or the opposite - take a product page and add a piece of content to it as a field, which can have its own comments, ratings, etc. Really flexible and powerful!

One sentence by Ryan got imprinted in my brain:

"Ubercart was the first PHP and MySQL project in my career, so you guys are pretty brave to use it in production"

Another session that stood out was the keynote by Rasmus Lerdorf, the creator of PHP. It really corrected the way I look at PHP. He also showed some tricks for debugging and tracing the performance problems for Drupal. It was pretty impressive how in 15 minutes he spotted that the bottleneck in Drupal is the rendering engine which he suggested to rewrite in C/C++.

One sentence by Rasmus that imprinted in my brain (with some distortion):

"PHP has always been a templating language. All the heavy coding must be done in C"

The session on Varnish was probably the geekiest of the ones I attended, but Paul-Henning Kamp (the creator) made his point - you have to use Varnish!

And I was totally impressed with Aegir, how come I've never stumbled upon it? There is no doubt that this tool combined with drush_make will save the world from the Drupal deployment hell.

All in all, there was quite some buzz about Drupal 7 during the conference, many serious modules are developed directly for 7.x. This is mostly due to the fact that 7.x has this concept of entity (a field) as opposed to nodes/comments, which solves a lot of problems. I'm really looking forward to Drupal 7 and all the goodies that'll come with it.

This was my first DrupalCon, and I must say that the crowd was really amazing. A bunch of friendly and easygoing people.

Understanding the Service Oriented Architecture (SOA)

2010-02-22T23:42:00.000-08:00

It's a pretty old term this SOA. A software engineer (or systems integrator) normally associates it to the interface based software design. Just take a bunch of components, define interfaces between them and implement those interfaces. Then each component suddenly can be called a "service".

Intuitively a service is something that you have an interface to and something that you don't care about how it's implemented.

There is a trend on the Web that websites expose their APIs to the outside world. E.g. YouTube, GCalendar, Twitter, etc. So suddenly those webapps become "services".

Consequently the Internet is a platform for running a huge application called "Web" that is designed in SOA way, where each site is (should be) a service.

Unfortunately we are still not building our webapps to support this. We're stuck with our software engineering mentality while we actually need to switch to Web engineering.

I think every feature of any webapp should be a service. Why coding and implementing your own contact form, your own blog, your own newsletter subscription module, your own user profile pages, etc.? Even if you have those features in your software package out of the box...

Looks like I'm trying to promote mashups, but that's only the tip of an iceberg. Imagine that you have a website that you properly Web-engineered. Say you built the contact form feature as a service and it's hosted on the cloud. And this feature is integrated into your CMS. There is a cool outcome at this point: you provide yourself with a SaaS solution. So you can actually start renting it to others as well. Ok maybe renting SaaS contact forms is not your core business... so what about doing it with the core business features? E.g. social graph, status updates, shopping cart, etc.?

Probably not everyone will go this way but just look at the beauty of this all, we've got services like getsatisfaction.com for feedback collection, discuss.com for comments, gravatar for a personal picture, openID for login, etc. etc. etc. The more a service is specialized the more useful it is.

For instance, a business model for Twitter could be renting their status updating feature to various social networks. Anyway every one of them are reimplementing it: LinkedIn, Facebook, MySpace, etc. Such a waste of time.

--
Posted from my Android

You Know, "running a business..."

2010-02-16T10:59:00.000-08:00

As soon as I tell somebody that I'm starting a business with several friends - I get a question: "what kind of business". And here a difficult part starts… At this early stage of 101senses it's pretty difficult to explain what we're trying to do, what we'll be in 1-3 years, what motivates us, etc. In fact, when I take a moment and think about it then things become quite straightforward and clear. So let me describe what 101senses is all about.

We are currently 5 guys in the team and we want to do fun stuff. The current job is a bit disappointing: you get on a project, you talk to clients, you start building a solution hoping that the client will have guts to go with something fancy and innovative. But then you end up in this quality vs. time vs. money triangle, and you just do what you have to do, not always what you want to. Well, that's IT consulting.

From several e-commerce projects I learned one thing: e-commerce is a good business. It's much better than building e-commerce solutions for others. For instance, a private sales module for Magento community edition costs 110$, and guess what's the revenue of a private sales e-shop...

But doing commerce is tough, and it's totally different from what me (and most of the 101senses team) is used to, because a big part of the business (at least in the beginning) is not virtual. One has to look for products that sell, people that buy, models that generate cash. All in all, totally new challenges from the ones in the IT world. So now we have the saying "IT part is easy". It's a lot of fun to observe how five guys are struggling with product sourcing and otaku searching - the two things that people have been doing for ages.

As a start we decided to sell stockings for girls. Besides the fact that for guys it's very exciting to deal with this kind of a product on a daily basis, there is real business rationale behind: stockings have a nice margin, take little space, and are easy to ship. So why not? Also if you look around the Web it's crammed ugly and difficult to use e-shops. In the times of the person-centric Internet this does not make sense and is an area for healthy competition. It's obvious that an e-shop that provides great user experience but the same products will win. We set an objective for 101senses to strive for the best customer experience in our e-shops. Prettify is going to be our first attempt.

Nowadays it's quite easy to implement an e-commerce solution we decided to work on 2 shops in parallel. We call them ShopA and ShopB. Prettify is currently our ShopA. The goal of it is to be able to test our process, i.e. get a product, sell it, and deliver it to the customer - no other requirements. ShopB is going to be based on a concept. It could happen that it will be an evolution of the ShopA but it's not excluded that it can become a totally different shop from Prettify. We're working on that by reading about exciting commerce and following various twitterers. We're also running from one conference to another, from one meet-up to another (check our calendar) and we're keeping an eye on fashion in general. It's getting more and more interesting everyday.

Most importantly we've got culture of openness and sharing at 101senses. There's no point in hiding what we do and how we do it. I believe it builds trust in the virtual reality - the Internet - the same way honesty does it in real life.

To summarize:

we're 101senses and we want to learn and do fun stuff

our first product is stockings on Prettify

at the core we've got the culture of openness and sharing

we like to engage into a public conversation online

we strive for technological innovation and great user experience on our e-shop

Some Experience With Google Wave

2010-01-28T23:52:00.000-08:00

For my personal projects I've got Trac setup (OForge to be more precise). Recently with several friends we started working on a new project - 101senses.ch - and for it we adopted Google Wave as a collaboration tool.

Actually we started with the wiki on Trac. But after jumping on the wave wiki naturally became obsolete, old fashioned, inconvenient.

Some observations about GWave:

It reminds a wiki in some sense, just that collaboration happens real-time. You don't have to browse through versions and diffs just to see recent updates.

The functionality of folders is ua bit cumbersome or sometimes even useless. At least I was not able to find any good use for them. The only thing I do is to apply a label "Meeting" with the saved search feature.

I start to fear that as the number of waves increases it will be quite a mess. Even now with 20 waves we already have duplicates. And there is no way to unshare a wave or delete it for everyone.

I really need workspaces. I'm working with different teams on different projects and mixing all the waves in the same pile just makes me loose an overview.

Widgets are cool but where do I find them? Would be great to have some kind of an app market on the web.

It's really great that GWave is open. Because I can extend it with my apps or change it with my own UI. I think it makes a lot of sense. If eventually GWave is adopted as a collaboration platform then we can expect many nice SaaS solutions showing up on the web. The competitive advantage will be determined by a set of features and the user experience, and we won't need to care about data portability.

- posted from my Android

“Liepsnojantis ledas” (“HotIce”) ir Šiaip Pamąstymai

2010-01-04T13:28:00.000-08:00

Šiauliai, 2009-12-27, “Liepsnojantis ledas” - renginys, kurio džiaugiuosi nepraleidęs. Ir ne vien dėl to, kad ant jo neįtikėtinas figūras raitė įvairiausi čempionai, bet ir todėl, kad kažkuriuo momentu supratau, kaip visa tai yra gražu.

Grožis yra sudėtingas dalykas ir man, savamoksliškai besigilinant į meną, jis ne visuomet apsireiškia. Pavyzdžiui, galiu klausytis Mocarto ausis pastatęs, bet kažkaip nepasiekia jis manęs, o va išgirdus Debussy, iš karto užlieja gerumo banga.

O kas ten dėjosi! Moterys sukdamosi skraidė. Vyrai jas kilnojo ir mėtė į viršų. Broliai mindė viens kitą su pačiūžomis ir vartėsi kūlvirsčia. Vieni krito, po to kėlėsi, po to greitai, kaip vilkelis, sukosi. Kiti ne tik kojų, bet rankų ir net kaklo vikrumu vertė publiką aikčioti. Stuburo lankstumas, špagatai, salto... Jergutėliau, ir tai ant ledo, su pačiūžomis!

Ačiū Povilui Vanagui ir Margaritai Drobiazko už jų Dailųjį Čiuožimą! Už tą romantišką plaukiantį šokį, kuris nuteikia taip pat gerai, kaip atlikus ar bent susiruošus atlikti kokį nors gerą darbą. Tai taurina, moko pajusti, gerbti ir didžiuotis vertybėmis.

Turi žmogus, matyt, kažin kokį receptorių, apie kurį per biologijos pamokas nemokina, nes jį nelengva įsprausti į trijų eilučių apibrėžimą. Pas kiekvieną jis sudirginamas vis kitaip ir pasireiškia savaip. Pavyzdžiui, jeigu nugara nubėga šiurpuliukas, reiškia kažkas buvo pasakyta, sušokta, pamatyta, perskaityta, patirta... negi ne? F. Dostojevskis sakė, kad Grožis išgelbės pasaulį. Aš juo tikiu.

Linkiu daug šiurpuliukų ir užliejančių bangų ateinančiais metais.

Grožis yra sudėtingas dalykas ir man, savamoksliškai besigilinant į meną, jis ne visuomet apsireiškia. Pavyzdžiui, galiu klausytis Mocarto ausis pastatęs, bet kažkaip nepasiekia jis manęs, o va išgirdus De Bussy, iš karto užlieja gerumo banga.

O kas ten dėjosi! Moterys sukdamosi skraidė. Vyrai jas kilnojo ir mėtė į viršų. Broliai mindė viens kitą su pačiūžomis ir vartėsi kūlvirsčia. Vieni krito, po to kėlėsi, po to greitai, kaip vilkelis, sukosi. Kiti ne tik kojų, bet rankų ir net kaklo vikrumu vertė publiką aikčioti. Stuburo lankstumas, špagatai, salto... Jergutėliau, ir tai ant ledo, su pačiūžomis!

Ačiū Povilui Vanagui ir Margaritai Drobiasko už jų Dailųjį Čiuožimą! Už tą romantišką plaukiantį šokį, kuris nuteikia taip pat gerai, kaip atlikus ar bent susiruošus atlikti kokį nors gerą darbą. Tai taurina, moko pajusti, gerbti ir didžiuotis vertybėmis.

Turi žmogus, matyt, kažin kokį receptorių, apie kurį per biologijos pamokas nemokina, nes jį nelengva įsprausti į trijų eilučių apibrėžimą. Pas kiekvieną jis sudirginamas vis kitaip ir pasireiškia savaip. Pavyzdžiui, jeigu nugara nubėga šiurpuliukas, reiškia kažkas buvo pasakyta, sušokta, pamatyta, perskaityta, patirta... negi ne? F. Dostojevskis sakė, kad Grožis išgelbės pasaulį. Aš juo tikiu.

Linkiu daug šiurpuliukų ir užliejančių bangų ateinančiais metais.

Arrange Fields in Trac Tickets

2009-12-21T11:18:00.000-08:00

I was struggling one day to organize fields in the order I want when I create tickets in Trac.

Copy templates/ticket.html into trac/myproject/templates/ticket.html

Insert the following code snippet to the beginning of the template:

<?python
  # define the order
  field_types = ["type", "priority", "milestone",  "keywords", "cc",  "component"]

  # Sorting function
  def sort_nicely(field1, field2):
    try:
        idx1 = field_types.index(field1['name'])
    except ValueError:
        idx1 = 1000 # no match, push to the end

    try:
        idx2 = field_types.index(field2['name'])
    except ValueError:
        idx2 = 1000 # no match, push to the end

    return cmp(idx1, idx2)

  fields.sort(cmp=sort_nicely)
?>

That's it, if you have any custom fields and you want them ordered, put them into the field_types list.

Magento and Drupal Integration

2009-11-11T09:30:00.000-08:00

There are numerous ways to integrate Magento with Drupal. Here I will share my experiences while working on that with very smart people at Optaros. I don't take credit for all the points in this post, because they are the product of the whole team.

The motivation for this kind of integration is the innovative look into where e-commerce is moving. To get a grasp of it look at OCentric. To keep it short, content is free advertisement for products. It allows customers to get more input about products and provides the meat for search engines to index.

Briefly, there are several main approaches to integrate Drupal and Magento:

let Magento be the main component, while leaving Drupal just as a subcomponent

let Drupal be the main component, and have Magento as an e-commerce module

let both Magento and Drupal be main components

These are general approaches and each of them have different pros and cons. They will be further detailed by usecases, complexity, technicalities, etc. in the following sections.

Moreover, we will release much of the code as open source, so it's not only a theoretical discussion here:)

Magento as the Main Component

This is probably the most acceptable approach in terms of implementation complexity. Moreover you can choose different level of complexity to implement.

The straightforward solution is to integrate on the service layer. Meaning that whenever we are on the e-shop product page we have to call a Drupal service to bring related content, for instance blog posts. The same holds for category pages. How to do that:

Create a Drupal module that allows you assigning categories and products to a content node in Drupal

Implement XML-RPC client on Magento side and use it to talk to services on Drupal in order to pull the content (e.g. using view.get or node.get funuctions)

Rewrite the category and product controllers on Magento to take the content from Drupal into account

There are some challenges in taking this way. They are mainly for those who want to implement features in a generic way. Specifically, whenever you add a CCK field or a feature like rating to a content type, you have some work to do on the Magento side. Namely, you need to modify layout and write templates to handle this additional data coming from Drupal. Hence it's pretty cumbersome to use Drupal community contributed modules as you need to do some coding on Magento side for every new Drupal feature. This is quite easy when the content from Drupal is read-only, but as soon as you want commenting, rating, flagging, etc. it becomes an issue, because you need to not only redo rendering on Magento but also map the functionality.

A more complex path to take is to integrate the whole Drupal rendering engine into Magento, however, this means a very tightly coupled architecture... Still, if you plan to use many many many of the Drupal features it may make sense. This will require writing a Drupal module for Magento that will adapt every Drupal core function to Magento. Could end up as a very complicated solution.

We chose the XML-RPC because of the given time frame and specific requirements. Normally a product or a category will be associated with a very specific set of content types, and therefore the fully generic solution may not pay off.

By the way there is already a CMS module for Magento as part of the core. And the question is why would one want to struggle integrating Drupal instead of using that CMS module? Moreover, with enterprise 1.6 version of Magento the module offers quite cool features. Some things from the top of my head to consider:

Drupal has a solid community, and it is more stable and feature-rich than the Magento CMS module will ever be (of course it's good as soon as you make the Drupal-Magento integration reasonably flexible)

There is the CCK module that allows to very quickly add additional fields to a content type and make it available to the content producing team

Content versioning, workflow, etc. is easy in Drupal

...more ?

Drupal as the Main Component

This approach has been already taken by others and you can start digging for it here. We've tried out the available modules but didn't stick with them... Basically there the implementation is based on the notion of synchronizing Magento products, categories, orders, etc. into Drupal using a cron job.

In general, although Drupal-as-the-main-component approach in the end may give a lot of flexibility, it may be too complex to implement. Imagine that the whole Magento frontend functionality needs to be rewritten for Drupal. Magento would then only be an e-commerce backend (the admin part) accessible via Web services. Of course you'd be able to use plenty of Drupal modules as well as flexible templating without any hassle, have better performance, and many other goodies but it just looks too expensive to implement.

Still, bringing only a part of Magento into Drupal makes a lot of sense (as in that module that synchronizes products and orders into Drupal using cron job). In this case it's a decision to make whether the site is more about content or about commerce. When it's about content, then you don't really care about SEO for products, fancy business logic, etc.

Both Mangento and Drupal as the main Components

This is reasonable when the content will be displayed on the Drupal site and e-shop on the Magento site. Meaning that no proxying for content happens behind the scenes. So if a product has a blog post attached, then on the product page you'll have a link (maybe even the post itself loaded using Ajax call) and clicking it will open a Drupal page with that blog post.

One of the challenges here is to maintain two different themes in order not to harm user experience. So that when the customer clicks on the blog link inside the product page the blog is displayed with the same look and feel as the shop. For that you can't avoid coding on two different frameworks. Apart from theming SEO will have to be also maintained on both components.

Another challenge would be the ability to mix content with product information on the same page. Some kind of communication on the service layer will be necessary for that, which means that it's not really reasonable to use this dual approach with such a usecase present.

It may make sense, however, to take this path when there are only some of the things to be shared between both components, e.g. users, and everything else is completely separate. For example, when a company has an e-commerce site, a customer community site, and a corporate site.

Additional Points for Integration

The end user display is only one part of the story. When you integrate this kind of monster systems to work seamlessly you get trapped with other things besides templating.

One of them is single sign on. A good thing to do here is to use CAS. Drupal already has the CAS module. Magento, however, needs one (we've been writing one). The good news that all the low level protocol implementation is available for PHP as open source.

Another thing is search. Independently of the integration approach chosen eventually you want to search for products and content in the same search box. This may become pretty challenging but it's not impossible. We've got a proof of concept for the store front in Magento, where we leverage Solr search. It performs really well for our suggest box functionality.

There are numerous ways to integrate Magento with Drupal. And here I will share my experiences while working on that with very smart people at Optaros. asdfa sfd

asdf adsfasdf asdfasdf

Interactive Projection

2009-11-08T11:50:00.000-08:00

I wonder if there is a technology that allows interaction with a projection. I was looking around the Web but all I could find was fancy and expensive (multi)touch screens.

I think it should be somehow possible to track hand movements from the outside only by means of a little camera and software; similar to the way eye tracking software works.

Imagine you put a little device that is watching how you are doing a presentation by projecting slides on a wall. As soon as you wipe the wall the next slide eases in; you zoom in/out with two hands the same way you achieve that with two fingers on iPhone; when you want to fast forward a movie you wipe with the faster movement; etc.

Probably the challenge would be not to stand in the way of the tracking device and, of course, to clean the wall you've been touching after lounch:)

Is HTC Hero for the left handed?

2009-11-08T01:50:00.000-08:00

Recently I obtained an HTC Hero and I really like it. I've never had an iPhone but my friends say it's pretty much the same. I say that it's the same but better. I always prove that with the Google Sky app.

One drawback though is that the "back" button (used very often) is on the bottom right of the device panel. So when you hold it in your right hand it's physically very uncomfortable to click that button. I mean very.

Content Maganement with the Delegated Features as Services

2009-10-26T06:08:00.000-07:00

As a friend of mine pointed out: there used to be a server and many terminals, currently we have a bit more sophisticated terminals - PCs - and our big server is the Internet, where the apps are "on the cloud". Nice analogy, and for me it makes a lot of sense. Are we really coming back to the terminal-server age but in a more advanced, i.e. distributed version?

Anyway I think that every feature in a Web application should be a service. Not a service in a sense of a mashup or SOA, but in a bit different sense.

Let's take a simple example - Drupal. It's a content management system. The power of it is that it's extensible with new modules that are normally contributed by the community. These modules implement different features, such as rate the content, comment, spam filter. One of the nice ones that I really like is made by the Drupal inventor Dries Buytaert, called Mollom. In fact it's a gluing module for the Mollom service, the service does spam filtering for your site. Specifically, when a person presses the "Save" button, the post first travels to the Mollom service, and then is checked if it's spam, in case it looks suspicious the user has to fill in a CAPTCHA in order to save the post.

Now consider that all the modules in Drupal had the Mollom nature. That is the module would just be the glue for the service which lives somewhere on the cloud.

A simple content driven site based on Drupal could be quite easily implemented with what's available out there. Consider a site for video sharing, kind of YouTube but maybe not so generic. At the core is Node - the most primitive content type made of title and body. And now let's add features as services:

Comment the node - Disquss.

Control the spam - Mollom.

Let users send the feedback about your video sharing service - Zendesk.

Rate the content - Outbrain.

Share the content - AddThis.

Video upload and related features - Kaltura.

What else? Well there is one more piece that I think is very important:

Social graph management. There are many services available out there starting with Facebook and finishing with QQ. These services expose APIs so there are also gluing modules for Drupal available. There is one caveat with social graph management. What features one wants to map, is it only friending or also status updates, picture sharing, etc. The purest approach would probably be to have a gluing module in Drupal that only uses authentication and friending features of the social service.

All in all, I strongly believe that paying for a feature as a service is better than paying for (re)implementing and maintenance of that feature. So it's like SaaS but on a feature level, not the whole application (feature set).

Audiobooks Social Network

2009-10-09T14:57:00.000-07:00

I like books. Recently I got attracted by audiobooks. This looks like cheating a bit, because it's not pure reading, however, I must say it's far from cheating. Listening requires (at least for me) even more attention than reading.

Anyway, I am now keen on audiobooks, and as it usually happens, my experience with the Web comes into play. So I started thinking whether it is a valid idea to build a social site fully dedicated to audiobooks - or more generally reading text aloud and listening to recordings.

Let me analyze the idea of this social site in several axes.

Social object

Clearly the social object would be a piece of read aloud material. For simplicity we can think of a chapter of a book. When all the chapters are available the whole audiobook is there. Interestingly, an audiobook can be assembled into one even if each chapter is read by different people.

Social activities

We've got chapters of audiobooks as downloadable files on the site. There will be two kinds of people visiting the site: those who submit their readings to the site and those who will want to download audiobooks. Besides all the usual features like sharing, bookmarking, chatting, reviewing, flagging, rating etc. audiobookers will need some special tools and features, such as: audioconferencing for real time multicharacter recordings, a friendly avatar that impersonates the reader, rankings of the best (popular) readers, transcription of audio into text for search engine optimization, and so on.

Technicalities

Software-wise everything looks solvable. It's just a Web site maybe with AIR desktop applications for reading aloud, saving, organizing, listening, etc. to books. The greatest challenge is how to ensure that the reader is reading the book the way it was written. And then, how to ensure that the readers will correctly name the pieces they read so that they (semi-)automatically could become one audiobook. Probably this is only achievable by croudsourcing and social filtering.

Business case

All the materials on the site should be available for free because it's community generated content. Still there are plenty of opportunities for paid services. For instance:

assemble audiobooks out of separate chapters for those who don't have time to do that by themselves;

sell professionally read audiobooks; allow the readers selling their recordings and take a percentage from each transaction;

provide additional tools for readers to promote themselves and get statistics;

organize paid events where book authors read aloud a chapter or two of their books;

use the audiobooking infrastructure for voice recordings management system as a service;

etc.

Tidy Up My Friend Feed

2009-08-17T02:14:00.000-07:00

There is one feature missing on Facebook (I believe in many other social networks as well) - digest view on friend's activity. Of course I can go to my friend's profile and see all the activity, but there should be something more user friendly.

Consider the following scenario:

I am on my Home page on Facebook. Here I see all the (non hidden) friend activity. E.g. somebody posted a picture, somebody shared a link, somebody liked a song. Apparently there are some people which are very active, so they do those activities very often during the day. Alternatively there are more passive friends doing those activities very rarely, e.g. once a week

In this scenario there are two things to notice:

Active friends will take up a lot of space on your Home page (or life feed in general).

Passive friends will be quite invisible in all the sea of posts.

It's very likely that an activity done by a passive friend is more valuable than 10 posts from a very active (and maybe not the best) friend. So what we normally do? We hide the posts of very active friends. Otherwise we put those active people to another list. All in all we want to clean up the main life feed on the Home page.

What we actually do is spam filtering on our friend's posts. That's not good, because we know that they are friends and the stuff they do is not spam (even if sometimes it does not concern you).

I think the solution to that could be a digest view on friend's activity. Mailing lists work this way. There I can specify, that I want to receive one e-mail per day with all the discussion topics listed. Following this approach would allow grouping all the posts of my active friends opposed to having them flat-listed by time.

A Browser That Removes Ads

2009-07-30T06:28:00.000-07:00

A couple of days ago my friend was very annoyed by an advertisement which produced some sounds when you mouseover it. And the ad was placed in such a way that he would go on it quite often.

I wonder if there is a Firefox add-on which simply removes the ads from a page. It would solve not only the problem that my friend had, but also a more generic one. Imagine it would be possible to browse ad-free, that should be really awsome.

The ad removal plug-in could be trained by users to detect ads, e.g. served by Google:). All the information about where the ads or banners are could be stored in some public database, and the plug-in could leverage the collective knowledge of all Web users. Considering that ads are normally served as:

external javascript

iframe

inline images or text

it should be rather easy for a browser to simply remove some pieces of HTML from the DOM or put them somewhere at the bottom of the page so that they don't disturb the eye.

Making Money with OAuth

2009-07-29T06:31:00.000-07:00

I am really excited about the idea implemented by RPXnow. It works as simple as:

... a proxy between third party identity providers and your website, RPXnow helps you effortlessly add single sign-on from providers like AOL, Google, Yahoo! and even Facebook. The hosted service runs in the cloud and is accessed via simple RESTful API calls ...

A set of features looks impressive, let me list them here (or see them with descriptions):

Supported identity providers: Google, Yahoo, Facebook, Twitter, MySpaceID, Windows LiveID, AOL, Blogger, Wordpress, VeriSign, Hyves, OpenID

Profile data from the identity providers

Account mapping

Extended access to the providers' APIs

Social publishing (coming soon)

Address book import

I want to note that RPXnow is positioning themselves as a "Single Sign-On for your website" although it provides with much more. And this much more, I think, could be a totally separate business.

RPXnow is putting effort to become a service that aggregates people data accross many services (e.g. MySpace and Facebook). Think of it as plaxo.com, but without the UI, just the REST API. Normally, if in your website you'd want to access user's MySpace, Facebook, or Google account data, you'd have to code everything yourself using the APIs provided by those services. RPXnow does it for you. So you only need to interact with one API - RPXnow API.

Recently I was reading the article Writing OAuth Gadgets, and then stumbled upon a concept of OAuth Proxy. As you can imagine it's a proxy design pattern applied for OAuth services, i.e. you provide an OAuth service that delegates to another OAuth service. Actually, the upcoming "Social publishing" feature of RPXnow will do exactly that - proxy to other services.

I think OAuth proxy could be a totally separate service in the cloud. There are many services online that allow for pretty much similar things: status updates, picture uploads, videos, profile information, etc. So the proxy could unify all this kind features into one interface and adapt to multiple services. As a customer of the proxy I would simply ask to upload a picture on behalf of a user, and I don't care where it goes - MySpace, Facebook or Flickr.

The question then if OAuth proxy as a business is possible without the "Single Sign-On for your website" like RPXnow. Because if not, then OAuth proxy would have to compete with RPXnow. I think it's possible. Consider a couple of use cases:

A website that already has a lot of users. Instead of changing there authentication strategy it may be more feasible to implement the "Link external account" functionality and use OAuth proxy

OpenSocial containers could use the more generic OAuth proxy than proxying just as a workaround

Maybe there are more?

Additionally, since OAuth proxy is actually software as service (SaaS) it implies recurrent revenue.

Remove an Account

2009-07-03T02:33:00.000-07:00

How I hate when I sign up for some service and then I can't remove myself from it. Of course for service providers it's fine, just several records in the DB, but for me... I loose control of my data.

What made me write this post is Audible. I thought, I'd buy an audiobook, and this service seems to be well known around the world. So I added my book to the shopping cart, and was required to sign up in order to proceed. Which I did, but then I was notified that I can't place an order because I am not in the right geography (I live in Switzerland).

Hell, I thought, and went to Amazon, but the audiobook store there actually brings you to Audible for downloads... And there I got the same message.

Ok, then it doesn't make sense for me to be on Audible, if I live in the wrong place:) However, I can't find the way to remove my account. All the credit card details are there, and I can't delete at least those... This really sucks.

Why Do We Still Maintain Those User Accounts on Our Services?

2009-06-26T09:45:00.000-07:00

Let's say you're building a website or an e-commerce site where you expect to have many visitors. By default you consider that people will need to log in to the site. When they log in, you'll collect some data about them. Sooner or later this data may be changed by the user on his/her profile page. This is a usual scenario, as old as web apps are.

And in every single project of that sort - the same thing: user registration, account management, password reminder etc. etc. If you look at a decent e-commerce software (e.g. Magento) or some content management system (e.g. Drupal) these features are built-in and looks like there is no issue with that. Surely, you can't have anonymous people doing things with your service. And of course user profile data is a very valuable piece of information.

But here is a paradox: by collecting this valuable user information we actually lose much other valuable (or even more valuable) information and when we realize that we need it (e.g. user social graph) we start building on top of what we have, in order to obtain it... Complicated life...

If we look around every single web site has a database of users. And this database is filled by almost always the same process:

Confirm your e-mail

Fill data in your profile

What about only one and a half step:

(modify information about yourself)

I strongly believe that the second case can be achieved using OpenID and OAuth and some code around them.

A big part of the account management feature in web applications can (and probably should) be delegated to third party services such as different social networks. This is because the e-mail is not a personal identifier anymore (just look at Google Wave - email is not there at all). If I play in a band I will most likely share my MySpace url; if I am a hardcore blogger, I'll give everyone the link to my blog; if I am networking on Facebook, I'll simply connect to people by their name. E-mail is good only to confirm one's identity, not to represent it.

A shift in thinking of web apps is necessary to go from 3-step account management to 1.5-step. How to do that?

Instead of registering user using their e-mail force them to sign up using their confirmed identity on another (trusted) service. For instance, if I'am creating a website or e-shop the default way for users to log in should be with Facebook or Google.

Prefil user profile with data from the external service as follows:
- Pull user picture (allow to swap it with his/her Gravatar) and other relevant info
- Let the user to connect other services to your application, e.g. Flickr, Facebook, or whatever makes sense.
- Ask for additional data that is not provided by third parties (preferably only when it's necessary to perform an action on the site)
- Allow the userto create a persona and define privacy settings

That's it!

Look at Google Friend Connect. Ok, it's very general purpose, not even sure if it's a very successfull project. Still it depicts how websites should operate, i.e. people should navigate around the web and have their social life present everywhere. That's how we live in reality: we travel to different places but are always in touch with relatives and friends via phone, email, etc. So every site on the Internet should have kind of "Friend Connect" feature instead of the stereotipical user management feature.

Of course, we can run into issues and questions like:

Identity mapping, when the user is allowed to sign in using different identities from different services

How expensive is it to build the user management infrastracture genuinly based on integration to other services as opposed to having standard (prebuilt) e-mail based implementations?

How much can one trust in the third party services? What if companies behind them go bankrupt?

But let me list the benefits from top of my head:

User is not required to sign up to yet another service, giving away the e-mail, memorizing the password

Since social networks will be like air, we're already integrating to other services through REST or JavaScript APIs. So why not doing it from the scratch?

Thanks to OpenID and OAuth as soon as another service appears it's relatively easy to plug it into your site if you've pluged one already

You get much more data about users on your site(e.g. friends, activities etc.), so you can track and engage in many different ways than just e-mail

The user experience of 1.5-step scenario is better than that one of 3 steps

Using computing resources of third party services

You might be able to bring your service to outside just your website, e.g. an OpenSocial widget on MySpace. This may turn into a viral effect which could increase the popularity of your service.

In short, let the people be free, don't close them in your little "walled garden", it just does not make sense, as you'll have to break the walls anyway :)

Relevant Search on the Web with a Personal Crawler

2009-06-24T04:48:00.000-07:00

I thought (and I strongly believe that somebody already thought about the same before me :D) that it would be great to have a search that's relevant only to you. With Google you can kind of personalize your searching experience, but I mean another thing.

Let's say:

I've got hundreds of followers on Twitter and I follow a hundred people

I'm on Facebook where I've got many friends

I'm using Delicious for bookmarks

I use Google Reader for keeping myself up to date

I blog myself, and I receive comments on my posts

etc.

In all the listed services/activities there is a substantial set of links present or produced either by me or by people in my network. These links form a slice of Internet that is relevant to me.

Intuitively, the part of Internet that is relevant to me is growing:

as I'm expanding my social graph

as I'm sharing links with others

as I'm actively participating on the Web, e.g. commenting

however, a big part of my subInternet is actually hidden (not public), e.g. links shared by friends on Facebook.

Now, imagine that you have your personal Web crawler (maybe plugged into Google). This way you could search in 3 modes:

The Web - as we are used today

The relevant part of the Web only - available via OAuth, Facebook Connect, etc.

Both

As an example consider the keyword "birthday" in all the three cases. It's pretty clear that the results will be quite different.

Platform as a Service (PaaS) or Cloudware

2009-05-29T07:54:00.000-07:00

PaaS, as Wikipedia puts it, is a bit clumsy to understand. You can get an expensive definition with examples from Forrester, if you will :) There is also the platformasaservice.com which seems to be (or to become) the central place for PaaS related resources. Also Google Search gives some useful links to read about PaaS, worth checking at least the first ten of them.

Why am I writing about PaaS? Because I got excited by the term, which I never heard or thought about.

Before not long ago I new SaaS, which currently is quite a comon business model - simply put up some software on your infrastructure and charge the users for using it. The best example in this area for me still is CRM provided by SalesForce.com. At Optaros we call this model Rent. You can read about Assemble vs. Build, Buy, Rent in the company's blog, pretty simple and quite interesting.

So SaaS is an genious idea. It allows for recurrent income, which is always good in hard and unpredictable times (provided that the customers are already there). Optaros realized that Assemble goes very well with SaaS in the way that we call Hybrid offering. To keep it simple the hybrid offering is: build the app and rent it (most likely to the same customer). Doesn't it sound more like a nice theory which is practically difficult to implement? Well, it is difficult but not impossible. Just check out what the Assembled Web is and then combine it with OView. Shortly, customers get a bunch of assembled apps floating around the Web and delivering their branded presence outside their main Web site. Moreover the customers get full control and overview over theoe apps. So this hybrid offering is really a simplified PaaS.

Having said that, looks like PaaS is actually a natural successor of SaaS. Intuitively it's something more than SaaS. What constitutes "more" is the delta between what is Software and what is Platform. Hence in PaaS business model it's a more complex software that's being rented. The complexity varies. It can be a virtual machine(s) that you rent, e.g. Amazon Elastic Compute Cloud, Google Apps Engine, etc. or infrastructure to build apps there, e.g. Bungee Connect, SalesForce.com, etc.

Interesting what goes next in the line of SaaS > PaaS > ???. Soon my laptop will contain no code, nor IDE... just a browser. And I will forget how JAVA looks like, what is PHP, what is scalability issues, etc. I will just program on REST APIs and buy resources from someone on the cloud. Sounds like fun.

OpenID + OAuth: Transcending Social Networks

2009-04-30T06:48:00.000-07:00

So we're tired of remembering all the log in details for each service we use on the Web. For instance, I'd like to log in everywhere with my Google Account because I use a bunch of services on Google. Others may be spending more time on MySpace and would prefer to log in everywhere with their MySpace account. OpenID allows for that.

Another thing, I want to log in to Facebook and see the pictures that my friends shared with me on MySpace. E.g. Plaxo is doing that in a very consistent way, by integrating many many services under one Plaxo's ambrella. That's maybe an exaggeration but with OAuth everyone can do this.

And so I am also doing that on my free time: playing with OpenID libraries and trying to integrate with other sites using OAuth.

The fact that social networks will be like air motivates me. And the fact that I will be able to login to Facebook with MySpace credentials hints that I am on the right track. Finally when I see services (with a business model behind it) based on OpenID (e.g. RPX), I am really feeling that the whole Web soon will change.

Backing up Drupal Quickly

2009-01-31T02:27:00.000-08:00

I must admit, updating a Drupal instance, even if it's one module is a bit scary. And a rule of thumb is: backup, backup and backup the backup. So I do it.

Below I post a script that I wrote for that purpose (my first script for Linux :D). The folder structure on my server is:

~/
~/files/
~/public_html/drupal-6.x/

The Script

today=$(date +"%Y-%m-%d")
drupal_v="6.6"
backups="files"

cd ~/
mkdir $backups/$today

clear

echo -e "TODAY: $today\n"

# 1.
echo "---Backing up Drupal 6.x without uploaded files---"

tar --create --gzip --file=$backups/$today/drupal-$drupal_v-no-files.tgz --exclude='sites/default/files' \
--directory=public_html drupal-6.x

echo -e "DONE\n"

# 2.
echo "---Backing up Drupal 6.x uploaded files---"

tar --create --gzip --file=$backups/$today/files.tgz --directory=public_html/drupal-6.x/sites/default files

echo -e "DONE\n"

#3.
echo "---Dumping the database---"

/usr/local/mysql/bin/mysqldump -u YOU -p --default-character-set=utf8 --result-file=$backups/$today/dump.sql DB
tar --create --gzip --file=$backups/$today/dump.sql.tgz --directory=$backups/$today dump.sql

echo -e "DONE\n"

#4.
echo "---Copying the settings---"

cp public_html/drupal-6.x/sites/default/settings.php public_html/drupal-6.x/.htaccess $backups/$today

echo -e "DONE\n"

#5.
echo "FINISHED. Please move the backup files to a safe location"

On Google Developer Day in Munich

2008-10-07T04:36:00.000-07:00

Yes, it was half a month ago, and I haven't posted anything about it so far. Shame on me.

General impression about the event is good. Although you couldn't avoid the feeling that there was a bit too much advertising. But ok, what can you do in one day wit 500 developers, besides talking to them?

Look and Feel

Since Google has this image of being cool, childish and friendly, it really kept this image during the day. As you come into the exhibition hall you get into kind of a huge lounge with fancy music and colorful places to sit and stand. Then you can go and play something, for instance, table tennis, table football, Lego, etc. And in the end you could directly speak to a group of developers from Google, as they were taking up a specific corner and therefore were always available. The organization of the event was really brilliant. Everything on time, food for free, projectors always working, no waist of time.

People from Google were friendly, helpful, and really proud working at Google. The main marketing messages they'd tried to convey were:

You can do it!

it's not there yet, but you can be the first one to develop (or create) it

We want to help people to grow in the Internet because Google can grow only when everyone is growing

We like open source, we encourage open source, everyone can be participate in projects where Google is also taking part

Not Only Brain Wash

The agenda was pretty compressed. You could attend at most 4 sessions (read descriptions)...

I chose: The State of AJAX, Android, A Deeper Look at Google App Engine, Codelab: Building an OpenSocial Application in the Cloud. All of them were interesting. As I knew the topics only superficially I really enjoyed more and direct information. Building an OpenSocial application was fun and helped to really understand what it's all about and what are the benefits of it.

What's out there relevant to GDD sessions:

The State of AJAX (presentation)

Android (presentation)

Google Chrome

OpenSocial: A Standard for the Social Web
[slideshare id=630660&doc=gddemea1munichopensocialupdate4-1222904875892477-8&w=425]

Apache Shinding - open source OpenSocial engine

Gears

Google Web Toolkit: The Technical Case (some older presentations)

A Deeper Look at Google App Engine (presentation)

Visualize your data: Google Visualization API

Geo

Google Developer Day in Munich

2008-08-18T01:36:00.000-07:00

If time allows I will participate in Google Developer Day in Munich. I am excited to have received the invitation and I hope I will have fun there.

Podcast on State of the Open Web

2008-08-12T00:14:00.000-07:00

Ajaxian.com, Dojo and jQuery stars talking. Download it or read an overview.

Comfortable OpenID Login Box for Drupal

2008-08-11T01:45:00.000-07:00

I've started a project (http://drupal.org/project/comfortid) which is intended to be a cool open source OpenID login widget for Drupal.

Looking forward to genious ideas on usability. I think it's the only way to make OpenID popular.