Facebook in Pidgin

Haudy Kazemi kaze0010 at umn.edu
Sat Nov 22 14:12:19 EST 2008


John Bailey wrote:
> Haudy Kazemi wrote:
>   
>> I don't think the average user cares what the reasons may be for
>> Facebook IM to be supported (or not) in standard installation of
>> Pidgin.  All they care about it is whether "it works" or "is
>> supported".  If the protocols they want to use or think they might use
>> are not supported out-of-the-box by Pidgin, that person is likely to go
>> onto the next multi-protocol IM application.
>>     
>
> I can live with that.  Most of our vocal users are on Windows, and my opinion is
> that Windows users will be better served by any application that doesn't use
> GTK+.  Let them use another client.
>   

Most computer users are on Windows, whether or not they have a choice.  
This itself biases observations of who is a 'vocal user'.  GIMP 2.6 has 
done a good job of becoming more Windows user friendly, while use GTK+.  
I think Adium, which also uses libpurple, is a good example of support 
Facebook chat, along with many other protocols.
http://en.wikipedia.org/wiki/Adium
http://www.tuaw.com/2008/05/09/adium-adds-facebook-chat-support-emo-kids-cheer-worldwide/

>> I think Facebook support is important, even if that is requires a
>> screenscraping design.  Facebook is incredibly popular, and for users,
>> it's chat feature somewhat parallels the ease of use of Gmail+Gtalk
>> (i.e. it's available as soon as the user logs in).  It is easier to
>> leave an IM program running 24/7 than to keep a browser window logged in
>> and then watch that window for IMs, so for convenience reasons it is
>> important to bring Facebook IMs under the unified Pidgin interface.
>>     
>
> Facebook is not important.  It's a time-wasting black hole.  (Yes, I use
> Facebook.)  If our reluctance, or in my case flat-out refusal, to support
> Facebook's chat in a crappy screen-scraping design is unpopular, so be it.
>   
Facebook can very easily become a time-wasting black hole, however 
separating its IM functionality from the rest of it significantly 
decreases that tendency.  When a user only sees one's friends in an IM 
application, there's limited ability for the other Facebook 
applications/frames to grab attention.  Many friends who do not use 
separate IM applications do check their Facebook accounts.  Facebook IM 
support is a way to contact them when they are online.

> Oh, so since other IM clients want to implement screen-scraping, we should do it
> too?  I remember being taught in primary school that "other people do it" is
> never a valid reason to do anything.  The context was, of course, different, but
> the concept still applies.
>   
That primary school teaching is simplistic, intended to get people to 
think first, act second.

It is a competitive advantage to support additional communications 
avenues, particularly ones as popular as Facebook (now at 120 million 
(!) active users according to their own stats).  This is around the 
number of users on the Jabber and AIM networks, and an order of a 
magnitude more than ICQ, Gadu-Gadu, or Sametime.  (See the user base 
summary here: http://en.wikipedia.org/wiki/Instant_messaging#User_base )

In business, having a minimum set of universally accepted features is 
called having an "order qualifier".  The premium additional features 
that aren't in every product yet are called "order winners".  
Multiprotocol clients use multiprotocol support as "order winners" over 
the standard clients.  They use user interface, customizeability, and 
protocol support as "order winners" over other multiprotocol clients.  
Standard clients use video/voice/game features as "order winners" over 
non-official (multiprotocol) clients.  An example of an "order 
qualifier" for any program is OS compatibility and being a relatively 
stable application (not crashing on a daily basis, and not losing data 
when crashing).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://pidgin.im/pipermail/devel/attachments/20081122/c4341524/attachment.html>


More information about the Devel mailing list