Saturday, August 15, 2009

A Next Generation Desktop Web Browser

The interface that web browsers provide today is one that is very similar to the first browsers that came out in the 90's. The back button, bookmarks, location bar are all very similar even though users use the web differently. On the smart phone there is a lot of experimentation of the interface, but the desktop hasn't changed much. Isn't it time desktop browsers got an overhaul?

History

Originally history was just a way to color links on a website so you knew if you had been to a link or no. To go with this history by default was stored only for a few days. These days browsers are designed to be able to store every single URL you ever visit. A history menu was a dramatic leap forward in usefulness for history and some browsers have begun to add more features to the history such as full history text search, screenshots, and more. While the history menu is nice it does have too many limitations. Is there a better way?

Bookmarks

A manually managed list of urls was nice back when the web was small, search engines were just being born, but the interface was created for adding urls, not managing them. Removing, sorting, filtering and searching is hard when by default it is shown in a menu. The Bookmark star solve so of these problems as it provides a way to easy remove bookmarks you no longer want. Some browser have begun to add features to the bookmarks such as the ability to tag, automatically updating, bookmarking rss and more. From adding, removing, managing, updating, syncing, meta searching everything about bookmarks is hard. How can a browser make bookmarks better?

Home Button

The home button is just a bookmark that happens to sit next to the location bar. Worse off it has a whole different way to be configured. Many browsers have already started removing this button by default. It is there because people expect it to be there. These days browsers run for weeks at a time, and have the ability to present a "new tab" page that shows the most common sites visited, arguably a much better home page.

Tabs

Tabs have problems. While there has been work in different design ideas on how to manage tons of tabs there are fundamental problem. We should not be putting time and research into how to manage hundreds of tabs, but into how can the browser help keep the user down to around only seven open sessions. Beyond the simple fact that users can't manager more then around seven of anything having hundreds of tabs means you could have hundreds of running JavaScript programs and you will run into system resource issues (not to bring up the fact that you have hundreds of dom's, images etc using up memory). As an experiment before opening a tab write down the reason for why you opened it. Very quickly you will discover the horrifying true problem.

Dialogs

Do you think asking a user to go down to seven tabs is radical? How about if if I asked them to only go to one? This is what is happening with popup dialogs. All dialogs related to a webpage should be part of that surface and not part of the browser. Already some browsers have begun to move some of the dialogs into the tab where it belongs. How can we move all of the dialogs into that tab?

"Private Browsing Mode"

Private Browsing mode as it is today if flawed. It was best highlighted when FireFox 3.5 users were horrified that there porn sites were showing up in the location bar search because they had bookmarked them in a "hidden" folder. When using Private Browsing it destroys much of the value that a browser can provide (history, bookmarks, autocompleting in the location bar, disk cache!) while not actually fulfilling the feature the user wants. Users don't care if they run into their porn, they just don't want anyone else to every see it. How can we provide what the user actually wants?

Visible URL

Before search engines you needed to put in url's a lot. It was only natural that this input field did double duty and automatically changed to the current url of the oage. Then we got a go button, autocomplete with history, the bookmark star, rss button, security warnings, a clear button, a site icon, search, and so on. The location bar turned in to the bastard widget where every feature gets put in it because it is always visible. While users still input url's with search engines and features like Top Sites this is much less so. Its primary function is to show the current url and removing that has to be done carefully because of security reasons, but already there are implementations out there such as the iPhone that show this can be successfully done. Ignoring all of the widgets dumped in the location bar the other purpose is to provide a crude command prompt into the browser for users. Is there a better way to display meta data, the current url and a way for users to input commands into the browser?

Menu Bar

Of course on OS X you will never remove the Menu Bar (unless you go full screen), but with no history, bookmarks, and dialogs, you don't end up with many commands. And with no location bar or bookmark toolbar it is temping to try to hide the menu bar to get screen real estate back. Making an Action button button like seen on browsers like Chrome shows that this is very doable.


Slightly better resolution than 320x480

There is a fair amount of research going on to make a browser UI for a screen that is 320x480, but what about a resolution that is 1920x1080?

Given that sites design to fix on a resolution of 1024x768 we can easily put two pages side by side on a monitor with that resolution. Given that that we don't have a menu bar, bookmarks (no bookmark bar) and are not showing the url or the site our interface (including window decorations) can be as simple as:

---------------
| META | META |
---------------
| | |
| LIST | SITE |
| VIEW | VIEW |
| | |
--------------

One of the primary reasons for multiple tabs is websites like Google Search or reddit where users are present a bunch of links. If they click on a link to see if it is interesting they destroy the current page. Hitting the back button 1) takes just long enough to make this expensive (sometimes really expensive) and 2) can result in the web page changing (such as on reddit) because the browser will reload the page. So users open the links in a new tab. What if when you clicked on a link in the Link List page it loaded in the Site View? How about loading an article on the right window and loading the digg comments page on the left hand side? The first week I had this in action and in use as my primary browser was mind opening.

Reading Lists

Watching how people use tabs you will notice an interesting usage pattern. Users are leaving a tab open because they want to come back to it later. This is often referred to as a Reading List and can also be called a complete failing our the existing bookmark system. For long term reading providing the means for users to quickly tag a page they can then close it. For example when researching a new car a user will leave open tabs that they find vary informative rather than making a bookmark folder. The second type of reading list is simpler. When doing a Google search a user might click on every search result in a new tab. The user will then read through each tab to see if it has the content they want. The browser should provide a way to quickly push links into a reading list rather then loading them in a new tab and conversely provide the means to pop the next item on the list or even clear the list. With the split views and reading lists users should be able to use the browser for a single task with only the two web views.

Buffers

An average human can only keep around seven things in their head at a time. Even if a browser can handle five hundred tabs the user is probably only thinking about the 493-500'th tabs. Each task view with the two windows is a buffer that can be layered. While split views and reading lists are great for a single task users often have several tasks such as reading news, gmail, and some Java docs. Providing buffers for each task will result on average around 7 tasks and 14 web views total rather then the tens to hundreds of unsorted tabs that users have today.

Ubiquity [http://labs.mozilla.com/ubiquity/]

If we take away the editable location bar how will the user go to a website? As mentioned before the location bar is a widget that has become smarter over time, but is still little more then a crude command line interface into the browser. The Ubiquity projects shows a much better route moving forward. You hit ctrl-space and start typing. A window that could take up the entire screen provides rich feedback about what you are typing. You can do all of the classical location bar commands such as manually typing in a url, 'go slashdot.org' or searching Google for foo 'g foo' or Wikipedia 'wiki foo'. But you can also have a quick calculator, translator and many others. Because it is text based it is extremely rich allowing you do do many things and can be easily expanded upon. [ See ubiquity for more info as they have spent time writing up nice simple descriptions and examples ]

Temporary-Buffer

Another reason users often open a new tab is to do trivial one off things such as typing a word into google to spell check it, going to whatismyip.com. While ideally these should be Ubiquity commands the user could cause a single web view to appear that floats on top of the buffer that the user can use for a short time before returning to the existing buffer.

Html Configuration & No Dialogs

A browser has a fair number of configuration options and yet due to the classic assumption about how configuration dialogs are presented there is no way to search a configuration dialog. Moving the browser configuration dialog into the browser and making it a web page gives all of the features a browser presents including easy searching and the ability to present many options in a scrolling interface.

JavaScript alerts, downloads, file dialogs all of these can be embedded into the web page. Popups will be local to the web page and while they might be able to block the page they will never be able to block the while application. A user giving a demo on buffer 2 will never have a popup blocking him telling him to accept a security cert for the site that is loading on buffer #1.

When access the MySite for the information about a web page would be flipped over and on the back would be the site configuration and information about all of the data, cache, history graph, and more. By flipping over the page you are not limited to a small dialog, but get the full size of the screen.

Guest Mode

Private browsing mode fails for the basic fact that we tell users to use it when they want to hide something. Users of course forget to use it from time to time resulting in them deleting their complete history out of fear. And to top it off when they are browsing porn because our browsers don't have their history and so we can't provide basic services such as letting them search their history for that video they really liked last week. Fail all around. What users really want is if someone uses their browser they will not see something. Given that our data is encrypted you must authenticate yourself on start any time you are not authenticated you are in guest mode. Really guest mode and private browsing mode are the exact same thing, but used differently. With private browsing you use it when you want to hide something, with guest mode you use it when someone is watching or when someone else is using your browser.

Meta Information

On top of the two windows is a meta bar which depending on the OS can be in the window title bar providing maximum web page space. This meta bar is created dynamically and while a default is provided users should be encouraged to customize it by making it trivial. It could be the classic back forward button, URL line edit, and search, but by default it could be the site title and the widgets that you often find in the location bar such as the RSS icon, the site icon, and network information such as if we are using SSL. The URL of the site could be a band at the top of the page that scrolls with the web page only needed at the start to confirm the site you are on.

Command Reporting

If you disable cookies, use adblock, or click to flash there would be a way for the user to see what the browser has blocked to easily unblock.

Plugins

A browser is only as rich as the extensibility that is provided by the extension framework. There are too many features that can significantly enhance the browser for a user that should not be part of the primary application.

The replacement for History or Bookmarks: MySite

MySite is the collection of all information about a site stored together where they can be more useful and provide richer features.

History and bookmarks are really one and the same and it is time we tried to keep the separate. History is sites you have been to, bookmarks are sites you have been to that you want to remember. As you move beyond two basic lists, the features quickly overlap. When was the last time I visited a bookmark? Can I sort a bookmark folder of links based upon when I visited them? What did the web page look like when I bookmarked it? Based upon my history what sites do you think I should (in the classical sense) bookmark? Every time you visit as website there is all sorts of information the browser can store to be useful for a user. To start with simply keeping the cache of the web page. This lets the browser:
- Full text search of every site the user has visited in every version.
- Offline browsing of sites they have been to
- Provide screenshots that can be used for all sorts of tools like a "Top Sites" page and a rich visual history browser.

Given that users have TB hard drives why are browsers limiting their cache to 50MB? Why not 50GB? Beyond just making day to day browsing faster having a full history can be very valuable. Research has to be done to see how much would be of value, but just defaulting it at 50MB seems foolish.

On the data side all data for a site should be stored in a single place. Rather then having a cookie jar that handles every site out there design a cookie jar that can be cheaply created for each new site that stores the cookies for that site. Deleting all the data for a site could be as simple as deleting the entire cookie jar (file/folder/database) with no possibility of bugs. With a cookie jar that only has the cookies for site X there is no possible way for a script from site X to grab your bank.com cookies in a hidden iframe or anything.

Each site should have the ability to customize every browser configuration for that site. Today some browsers let you turn off a few things such as cookies for a site, but why stop there? Every single configuration option related to the web page should have the ability to be customized on a per site bases. Cookies, custom stylesheet, zooming factor, fonts, etc. This is done in a way that is cheap so each tool and addon (see adblock, and many similar tools) don't need to re-invent the exception/whitelist dialog.

MySite should store the URL's that were browsed including the referral URL and meta information such as how they left the site (click on a link, went to a bookmark or closed the tab), where was the scrollbar. This valuable information is small and can provide rich history/replay browsing later.

Rather then bookmarking a site, a user will tag a page with a bookmark. Free form tags on any page allows a user to not only quickly mark a page, but also add meta information about why they tagged it. Pages can have multiple tags and searching for tags is the default method for accessing tags. Tags are cheap, the user doesn't have to decide to bookmark a page, there is no tag management or bookmark menu tree to keep clean.

How valuable is your browsing history? Browsing history is literally your thoughts in computer form. Walking through the history of the CEO might tell you that he has been spending a lot of time reading up on a some small startup. Is he looking to buy it? What if that CEO was Steve Jobs? How about going through the average users history? You will discover where they are thinking of going on vacation, what car they might buy, where they get there news and probably what fetish they have. What if you saw someone was searching for "How to make an atomic bomb", "How to kill my wife/husband", spending time looking at Monster.com, a medical sites, a forum site where they post under an alias. This is pretty private information. If you were to sell a diary application what would be the first thing you would offer? Encryption. Given the amount of time users spend in the browser and how sensitive the history data is it is insane that browsers don't offer full encryption by default.

[http://www.chromium.org/chromium-os/chromiumos-design-docs/protecting-cached-user-data]

MySite has to parts, cachable and non-cachable. You can (usually) re-download a webpage, but you can't re-download your cookies if they are deleted. The non-cachable parts should be in a form that is sharable so they can be on multiple computers. From multiple computers, to reloading an OS what is the value of having a history that can hold 100 years of links if every six months they reload Windows?

While initial I did say that you should remove all of the classical UI elements that a browser has all of the backend changes could support the classical view, but that would destroy a lot of the value of those changes.


Further notes and ideas:

More Meta Information
There are various history tree viewing examples out there such as: https://addons.mozilla.org/en-US/firefox/addon/13316/

Direct History Views

From the Summer09 Mozilla labs design challenge TabViz
http://design-challenge.mozillalabs.com/summer09/

Wednesday, May 13, 2009

Open Qt repository and hidden gems

On Monday Qt Software launched the public repository for Qt. Already there are more then a dozen patches waiting for review in the merge request list and no doubt there will be many more. To help developers submit patches that are higher quality and more likely to be accepted a number of documents have been published on the Qt wiki. Beyond the wiki in the source repository there are new things that could not previously be found in the snapshots or releases. With so many new things I wanted to highlight a few of the items I found most interesting.

Qt Coding Style Followed not only by Qt, but by other projects such as Arora and applications in KDE. Having a common coding style makes code easier to read and review. In the past few years I have seen many applications adopt this style and I look forward to seeing the usage grow.

Api Design Principles An updated version of the old Qt Quarterly article Designing Qt-Style C++ APIs from the first paragraph: "This document tries to summarize the know-how we've accumulated on designing Qt-style APIs. Many of the guidelines are universal; others are more conventional, and we follow them primarily for consistency with existing APIs."

The Little Manual of API Design by Jasmin Blanchette’s In the wiki page for Api Design Principles you find a link to the this pdf which is now public. This first rate book should be mandatory reading by any programmer. While many of the examples are from Qt and in C++ most of its ideas apply beyond Qt and C++. Rather then doing it a disservice and trying to describe it, here is the table of contents which gives a good overview.

1 Introduction 5 
2 Characteristics of Good APIs 7 
2.1 Easy to learn and memorize . . . . . . . . . . . . . . . . 8 
2.2 Leads to readable code . . . . . . . . . . . . . . . . . . 9 
2.3 Hard to misuse . . . . . . . . . . . . . . . . . . . . . . 10 
2.4 Easy to extend . . . . . . . . . . . . . . . . . . . . . . 12 
2.5 Complete . . . . . . . . . . . . . . . . . . . . . . . . . 13 
3 The Design Process 15 
3.1 Know the requirements . . . . . . . . . . . . . . . . . . 15 
3.2 Write use cases before you write any other code . . . . . 15 
3.3 Look for similar APIs in the same library . . . . . . . . 16 
3.4 Define the API before you implement it . . . . . . . . . . 17 
3.5 Have your peers review your API . . . . . . . . . . . . . 17 
3.6 Write several examples against the API. . . . . . . . . . 18 
3.7 Prepare for extensions. . . . . . . . . . . . . . . . . . 18 
3.8 Don’t publish internal APIs without review. . . . . . . . 18 
3.9 When in doubt, leave it out . . . . . . . . . . . . . . . 19 
4 Design Guidelines 21 
4.1 Choose self-explanatory names and signatures . . . . . . . 21 
4.2 Choose unambiguous names for related things . . . . . . . 22 
4.3 Beware of false consistency . . . . . . . . . . . . . . . 23 
4.4 Avoid abbreviations . . . . . . . . . . . . . . . . . . . 25 
4.5 Prefer specific names to general names . . . . . . . . . . 25 
4.6 Don’t be a slave of an underlying API’s naming practices . 26 
4.7 Choose good defaults . . . . . . . . . . . . . . . . . . . 27 
4.8 Avoid making your APIs overly clever . . . . . . . . . . . 28 
4.9 Pay attention to edge cases . . . . . . . . . . . . . . . 28 
4.10 Be careful when defining virtual APIs . . . . . . . . . . 30 
4.11 Strive for property-based APIs . . . . . . . . . . . . . 31 
4.12 The best API is no API . . . . . . . . . . . . . . . . . 32 

Codeing Conventions and Binary Compatibility Workarounds Two good documents that walk through a number of issues that Qt has to deal with being a library that is used on many platforms and compilers. An interesting read for anyone who uses C++ or Qt.

Autotests and Benchmarks After several years of discussing it, the Qt autotests have finally been published. Everyone in KDE can finally checkout how class Foo is tested and when writing patches for Qt an attempt should always be made to write a matching autotest. See some interesting usage of qtestlib and get plenty of example of how to test gui widgets. For those who are writing their own tests check out my QAutoTestGenerator tool which generates test stub files for you to help get you started. Hopefully having this large set of tests open will encourage more Qt projects to have tests. For those who are using Git and qtestlib I have written a git hook that can be found in the Arora repository that will run the matching autotest for files you change to check for any regressions before committing.

The full commit log for Qt While in the past the qt-snapshot git repository gave a one day granularity the new repository includes every commit with the commit log. The other day while tracking down the QTemporary bug in 4.5.1 I wrote a little test application and Thiago used git bisect to find in twenty minutes the exact commit that had caused the breakage.
git bisect start HEAD v4.5.0 -- src/corelib/io
git bisect run sh -c 'LD_LIBRARY_PATH= make sub-corelib && (ulimit -n 250; /tmp/qfile-bug/qfile-bug)'
With the full commit log tools like bisect and blame become even more useful for inspecting the Qt source code.

With the Qt source code on Gitorious it will be easier for developers that need a bug fixed to help contribute and get it fixed in Qt faster. Those who use Qt and want to understand how something works or why it was developed in a particular way will be able to more easily explore the code base. And maybe KDE can even remove the legacy qt-copy. No doubt many good things will come out of the open Qt repository and I look forward to seeing what the community contributes.

Wednesday, March 18, 2009

PlanetQt.org launch

After more then a year of thinking about doing it I finally setup planetqt.org and after getting the initial kinks out am officially launching it. While KDE is a major user of Qt there are many applications and developers out there who are not part of the KDE project or who's blogs/news really don't really fit on planetkde.org (or the freedesktop planet). Because of this there are a lot of really interesting Qt projects/tools/stuff out there that people don't know about. So that is why I started Planet Qt. Being made up of people I thought the frame from the Qt4 dance seemed to be a nice logo.

Submit atom/rss feeds for blogs about Qt development or the news feeds of applications/libraries that use Qt and I will add them.

Enjoy!

Monday, March 02, 2009

Tiling An Image With FractalFill

Last summer Adam and I looked into how to speed up tiling an image. In particular we were using QImage (Not a QPixmap so X11 isn't involved in this) and tiling an image on it. This is a pretty common operation, especially on the web where many web pages have repeating backgrounds on items. We came up with a few different ways to do this in Qt.*
  • Naive
    loop over the height 
    loop over the width
    fillRect(tile)

  • QPainter::eraseRect
    Set a background brush to be the tiling image.
    call painter.eraseRect(QRect(0, 0, image.width(), image.height());

  • QPainter::fillRect
    call painter.fillRect(QRect(0, 0, image.width(), image.height(), brush(tile));

  • FractalFill
    painter.drawImage(0, 0, tile)
    while we haven't reached the width and height
    copy everything we have done so far to the next location

Benchmarking this we discovered that eraseRect was pretty horrible, but much more surprising was that our FractalFill algorithm that we tossed together was faster then all of Qt's method. (If any graphics ninja's want to suggest a even better algorithm we are all ears) Adam blogged about this some of the Trolls responded saying that Qt's painting had improved in a private branch which would be part of Qt 4.5. Now that Qt 4.5 is almost out I thought I would revisit to see how the painting performance numbers shaped up to be.

Along with the four algorithms there are two more that are added to the benchmark (Colored yellow in the graphs).

  1. A base line, something that we shouldn't be able to be faster then: just calling painter.fillRect(QRect(0, 0, width, height), color);

  2. Using the FractalFill to paint the whole image with a color.

First up is RGB16 with: 1000x5000





Qt 4.5 really has improved upon Qt 4.4. The problems in eraseRect are gone and everything is faster across the board moving to 4.5 and even better when using the raster engine. But more surprising is that FractalFill is still faster then the two QPainter functions.

Same format (RGB16), but in a larger size: 5000x5000





Again it is clear that eraseRect has been fixed and overall painting has been improved slightly.

Moving on to ARGB32: 1000x5000




And in 5000x5000





On this last one with the larger image sizes I started getting larger differences in the tests results. On ARGB32 the performance seemed to be about the same or slightly better.

Overall performance is much better in Qt 4.5 then 4.4. A big congrats to the Trolls for all their hard work. Painting speed has improved across the board decreasing the runtime of all of the functions. FractalFill is still faster then using QPainter's fillRect or eraseRect so for the time being if you looking for something faster then Qt's fill functions for tiling this might be useful for you.

Notes:
I have uploaded the source for the test application to a GitHub repository. I ran the application multiple times on my computer to generate the numbers using the release version of Qt, building from qt-snapshot with 4.3.2 on ubuntu and qt3compat turned off. Now that Qt 4.5 is out it would probably be worth converting to the new benchmark tool. I used Google's graph service to generate the graphs.

* Analyzing each algorithm to determining their Big-O notation is left as an exercise to the reader. ;)

Friday, February 20, 2009

Arora 0.5 and Oxygen Style



Tonight I tagged Arora 0.5. And with every release starts development on the next release. One of the things I would like to improve for 0.6 is integration with KDE4. To help do that I have started a wiki page of KDE4 items. When using Arora on KDE a bunch of the first issues everyone runs into are really just improvements that need to be made to the Oxygen style. Little things like returning the KDE icons for back/forward, returning the correct size check boxes in QtWebkit, and supporting the new QTabBar style hints in Qt 4.5 will really help Arora fit in better with KDE 4. Of course these fixes will benefit everyone who uses QtWebKit in their application and anyone KDE application that uses the new QTabBar features. So I am putting out a request for help. If you happen to have your box all setup for KDE development and have a few minutes to spare helping making Oxygen an even better style would be most appreciated.

Friday, February 06, 2009

Comments rating systems, a close look at giving points

On many social news sites users can give and take points on comments. The purpose of the points is to give hints about what comments are worth reading. But upon closer inspection this method often fails to provide a way to let the sites software sort or highlight good comments.

A lot of time and effort is spent perfecting the algorithm used to generate the order of stories, but when it comes to user comments on each article the trend the past few years has been to allow any user to vote up or vote down a comment and to sort on the values. This up down method seems to provide very little real value and produces very poor results as a means of sorting.

When a user sees a comment the basic version of the algorithm that users go through is something like this:

"If I see a post that looks good I vote it up. If I think it is wrong I vote down."

The number of points a good post gets is directly related to the number of users that read the post. The more users read the post the more are likely to award it points. A good post A posted at time 0 could get 100 points and the same post made at time +1hour will get 50 points and the next day will only get 3 points. At the same time a bad post B posted at time 0 can still get 8 points.

Or to sum it up with one question:
Is a comment with 47 points better then one that has 46 points? Frequently you will find the answer to be yes, no, and maybe depending upon when the post was made and having very little to do with the actual content. Because comments are not created at the same time the points that they each get can't accurately be compared without taking into account extra information. You could take into account the time sense the article was posted, the number of people who saw the comment, the number of people who voted on comments and the total votes given at the time when the vote was cast. All this does it make it more complicated so the same system can be used rater then asking of the system should have been used in the first place.

For many of the social new sites the comments were second fiddle to the main page. Once the jewel of the site the article sorting was working then comments were added. Many social news sites the past few years have employed some sort of up/down voting system for articles. Developers being developers decided to reuse this same code on comments. Lets users up/down vote on any comment and sort based upon value and blam job done in no time flat. Of course the article sorting isn't actually based upon only the value of votes, but takes into account time as a factor of the ranking.

It seems as though sorting comments was created out of the laziness of developers. They do have one thing going for them though. When a site is small there will not be too many comments on articles so users can quickly read all of the comments. For a small number of comments the sorting doesn't matter that much. It is only when you get a large enough base to get many good comments that the issue comes to light. Of course by that time if you have lots of users there is no real incentive to make the site better because the incentive of making something better to get users is diminished.

While social news sites think that their secret sauce is the front page I wouldn't be surprised if the comments page was of much more value. After playing around with the issue for way to long I ended up with a model very similar to the one slashdot already has. For any given comment it can be ranked from -5 to +5 and given a type. You end up with comments that have ranks like: +5 funny. +4 informative, -3 troll, etc. It takes very few users to agree that something is informative or funny and should get a value of -3 or +5.

The number of points a good post gets is directly related to the value the users find the post to be. This will results in the comment changing values less and less as time goes by (reaching its true value). A good post A posted at time 0 will have 0 points, but two minutes later will be at 3 and from then on some might say it is 2 some might say it is 4, but it quickly approaches what everyone feels the comment actual worth is. Compared this to posting the comment A after one hour and it will probably again be marked at 3 by a few users. This allows for much better comparisons between comments.

Combined with the small point scale is adjectives. This makes the user not just say "I like this", but have to think about what they like which results in much better scores. It also gets the added benefit of allowing users to do things like automatically give -1 points for funny comments if they find them annoying (or +2 in the opposite case).

To add to the debate there are several live examples of the different systems (often times they even cover the same article!). First going back to the objective which is to rank or highlight good comments for readers so they don't have to read everything. This includes getting rid of junk/spam/trolls. Now head over to slashdot and click on an article from yesterday. View comments by default it shows +4 and higher. They are pretty good and informative. Now go to reddit. While it is able to get rid of spam comments it displays everything having no such thing as +4 or higher and even if you sort by Top you still find that that non-informative, but early comment (which may or may not be really good) is right at the top with a huge number of points and you have to scroll around reading everything, attempting to find a post of any real worth. The good comments are just as likely to be near the bottom with 4 points as near the top with 400. When a social news site is unable to bring good comments to the viewer a good chunk of the value of the social new site is lost.

Having points for comments is a system that is so easy to implement that it will probably never go away, but a closer inspection shows that it really doesn't do a good job of the basic feature it was created for which is to allow the system to give hints about what comments are worth reading.

While I doubt many sites will change what they are doing this will hopefully spawn some conversations for developers who are creating the next generation social new site. While the slashdot system might not be the best we need to take a step back and look to see what the objective of ranking comments and how to best achieve that.


Photo by dougww

For another fun comparison blog like this one see the blog post that discusses two different ways to find the most attractive girls.

And for a blog discussing problems with giving users infinite karma points checkout Joshua Gross's Qualifying “Web Karma”: It shouldn’t be a game.

Update: Reddit has switched to a new comment system that attempts to resolve several of the problems listed. Read more on their blog: reddit new comment sorting system

Sunday, February 01, 2009

Chromium On Linux (Part 2)

I have been following the Chromium development the past six months as Google attempts to get Chrome working on the non-Windows platforms. In the process I have watched as they rediscovering that creating cross platform application from scratch is hard. Following up on my first blog entry on why you don't have Chrome on Linux today as a Linux user recent Unix platform discussions are just too amazing not to share.

On OS X the plans is to redo all of the UI and use native Cocoa API. There seems to be very little debate on this as there are many positives including a strong consistent API with a growing fickle user base. They still plan on doing their own window painting and not using the OS X theme though.

But on Linux is it a different story. Linux has very few users and those users like to use many different things and have different expectations. Rather then using a library one options would be to re-use the code from Windows. Chrome has an internal library called "Views" which wraps some Windows API/widgets and implements from scratch others. On the mailinglist Evan (one of the kick ass Linux Chrome devs) mentions how they are already duplicating work that already exists in Gtk.

"Pawel recently posted a patch to abstract out the views keyboard event handling for our "button that looks like an HTML link object". Well, there's a built-in one we could've used: http://library.gnome.org/devel/gtk/unstable/GtkLinkButton.html"

Not only Gtk, but Qt also has a widget that can do this. But this is just the tip of the iceberg as they are forced to port each feature from focus handling to widgets. The biggest thing though is that Chrome's tabs go all the way to the window boarder on Windows. On Linux this means to get this they would have to turn off the window manager decoration and do all the painting and window handling on their own. Even though they admit that "it's endless pain" they are pushed to do this for branding and experience reasons. One of the developers even suggested that this would be something for the Linux developers to do in their 20% time.

"What about rolling out [using the window manager] initially, then implement [drawing everything] as a 'group 20% project', the group being the linux team" (1)

Google developers have reported that many never actually use the 20% time contrary to Google's HR marketing and I guess it has gone to such extremes internally that now the 20% time is thought of as time you get to spend doing project tasks.

Working on Arora I planed from the start to have Arora working on different platforms. Even switching between Gnome and KDE icons, button order, shortcuts and more will change. Looking through the screenshots you can see that Arora does a decent job of integrating with each desktop. Many Linux users are geeks, the very type that would download Chrome's source, improve it, write plugins and more. Actively not wanting to fit into their desktop doesn't seem the best route to take.

While they can always change their mind, for now the push in Chrome seems to be to do their own window boarder painting and handling, porting the views (creating a new cross platform toolkit?) and not bothering about real integration with any Linux platform until later.

Or to sum up in the words of Ben Goodger:

"Yes there will be some number of people that squeal. But honestly how bad will it be?"

1) http://groups.google.com/group/chromium-dev/msg/9146805bb27ba30c?dmode=source
2) http://groups.google.com/group/chromium-dev/browse_thread/thread/b89ab99a0c848b89#

Wednesday, January 14, 2009

Qt 4.5 will be released under the LGPL.

This morning Nokia/Trolltech announced that starting with version 4.5 all versions of Qt will be also released under the LGPL 1.2.

This bit of news is absolutely jaw dropping amazing. Game changing amazing.

Near every scenario where toolkit X was chosen over Qt now gets to be rethought. Can't afford a license? Boss wont let you buy it or even get a trial because of the cost? Only allowed to use software that you don't have to pay for? Only want to use LGPL software for philosophical reasons? In all these cases now you can use Qt. No doubt there will be considerable amounts written about this change in the coming months.

Shortly after I first got into Qt, Gnome was formed in response to KDE and in particular Qt's non-free licensing at the time. A few months later Qt was released under the GPL, but Gnome and Gtk had picked up steam and continued to be the projects they are today. Part of that was that GTK+ was released under the LGPL. So for the last twelve years I have unfortunately heard many discussions more about licensing then about the technical nature of the libraries. After all this time for that wall to be abolished is stunning. So many years of licensing and wham, in one day it is gone! The emotions will still be there and it will take time, but now that both libraries are under the same license hopefully developers will be more willing to combine efforts and choose tools no matter what toolkit they use.

Developers and startups that want to make applications that they hope to eventually make money while keeping the source closed will be much more open to the idea of using Qt. In the corporate world having Qt under the LGPL will allow developers to bring their Qt experience into the office to get jobs done and show off the capability and power of Qt without having to go through the hassle of getting a trial license. Companies that don't want anything to do with GPL or LGPL can of course still buy a commercial license.

From QString, QtWebKit, QtConcurrent, and Designer Qt has many useful components and it will be interesting to see how people use it in the future. This license change will no doubt open many more doors for Qt. Combining free, high quality, and cross platform is a killer combination. Qt's API is fantastic and the documentation is first rate. This change will only cause Qt's usage to increase across the board and the need for developers with Qt experience to increase. A solid way to build applications on every platform and what matters most for many, free.

I have no doubt that interest in QtWebKit and my own little project Arora will increase. Putting Linux with Qt Embedded and WebKit for free is a slam dunk. Interest in WebKit has been growing by leaps and bounds the past year and it will only increase more in the next. QtWebKit backed by a LGPL Qt provides a very attractive solution for many. Only time will tell what happens of course.

From playing around with Qt back in 1996, being part of to KDE, creating applications for the Sharp Zaurus, working for Trolltech on Qt itself, and contributing to WebKit it has been an amazing twelve years and I look forward to see where it goes in the next twelve.

Popular Posts