27 November 2006

Softpedia Review

Today I got a notice that there is a new Softpedia review of Liferea. It is interesting to read and gives Liferea an overall rating of 3 out of 5 points. I think this qualifies for "not completely useless". From the functional standpoint out of the possible aggregator features known today this is a good characterisation.

On the negative side the review makes the assumption that Liferea aims for GNOME integration which it doesn't. This is a very common mistake out there. This brings me to two questions:
  1. Does the project wrongly communicate a non-existing GNOME integration?
  2. Is there an overwelming need for GNOME integration?
If the answer to question 2 is "yes" then what are the resulting benefits for the user? Besides some more GNOMEish dialogs and toolbar?


Anonymous said...

I'm convinced the only thing the writer seemed to want in the way of GNOME integration was clicking a feed link and have it added to liferea automagically. (Or something like that.) I can't imagine exactly what else his complaints are about.

I think on the front page of the homepage the last sentence of the description ends with "for GTK/GNOME" might be a bit misleading. Perhaps "using GTK" might be better at implying it uses GTK libraries and isn't intended to be integrated with GNOME.

I would have rated it higher and but I use it daily and would have a hard time keeping up with sites without it. Keep up the good work.

Lars Lindner said...

For the GNOME integration there are both an Epiphany and a Firefox plugin. Epiphany delivers a default plugin that allows adding subscriptions to Liferea and for Firefox 1.5.x there is the FeedBag extension, for Firefox 2.0.x+ there is the "liferea-add-feed" command. All three mechanisms allow one-click subscriptions.

You are right with the "GTK/GNOME" wording. It is misleading from the integration standpoint. The problem is there are users asking if GTK programs can be run with GNOME and vice versa.

Thanks for your opinion!

Lenny said...

I'll be very frank with you.

I think Liferea is a great feed reader. But I would like that it follows some of the Gnome Interface Guidelines.

I have a problem with the menus. Using GNOME, I'd expect that the first menu is 'File' or 'Feeds' in this case, and not 'Program'. Also I think the app need a 'Edit' menu, because sometimes I need to copy something and I'm often lazy with the shortcuts :-)

Oh, and with the toolbar, if in gnome-ui-properties I select button labels to be beside the icons, every icon in the toolbar of Liferea is labeled, but I'd expect that only some of then be labeled.

Can you try to do these changes? If you do, It would be great, since it disturb me a little these inconsistencies.

Thanks for your time.

Spoială Cristian said...

For the GNOME integration there are both an Epiphany and a Firefox plugin.
I sent a email to the editor and I hope he will do a new review to the final version.

Kurt McKee said...

I don't think that the program needs to integrate with Gnome any more than it already does. However, as Lenny indicated, it would be VERY appreciated if Liferea conformed to the Gnome HIG. Liferea stands out as the most anomalous interface on my desktop.

My biggest request right now is Gnome HIG conformance! Thank you for working on Liferea!

Lars Lindner said...

Well after so many requests for 100% HIG conform menues (there were several discussion in the mailing list too) I think I'll change it in the soon to be started 1.3.x branch. Although I personally find it confusing to have no "Program" menu collecting the actions to control the program itself I see the advantage of following the approach most GNOME and GTK applications do.

Lars Lindner said...

@lenny: I'll have a look at the toolbar issue. The idea is to follow the GNOME settings. There is already a similar open bug report about this in the SF tracker.

Lenny said...

Thank you!
It's great that you consider the feedback of the users.

I hope your best.

Lars Strojny said...

As the GNOME-world lacks a feed reader, liferea could fill this gap. Maybe someday it could be shipped as a GNOME-application. But I guess this will require some UI-changes, as well as technical changes.
1.) HIG-conformance
2.) Other plugin language
3.) Integration with evolution-data-server (the contact-stuff has a field weblog)
4.) Integration with galago ("Send the author an IM", when he is online)

Lars said...

Yes, going GNOME would mean a lot of extra effort both from the organizational work and from the function integration efforts.

Allan said...

Liferea stands out as the most anomalous interface on my desktop.

You don't use a lot of apps, do you? :-) Let me see from the projects list:

Rhythmbox: First menu is 'Music'.
Beagle: First menu is 'Search'.
Ekiga: First menu is 'Call'.
Totem: First menu is 'Movie'.


Gaim: Menu is 'Buddies', 'Accounts', 'Tools', and 'Help'.

You get my point. I do agree that Liferea should conform to the interface guidelines, for some definition of "should" which does not imply too much urgency.

Yes, sort out the menus - that is probably not too hard.

Yes, you'll probably need a more standard plugin language. That probably means Python. And yes, I remember your discussion here on why you made the choice you did. It probably still means Python. I, for one, welcome our new master....

Evolution: Good point. Perhaps for the 1.5 branch?

Lars said...

Sometimes I have the impression if the HIG would say the first menu group would have to be green, italic and to be rotated 180° people would still demand every GNOME related program to implement it.

I do not want to say that the HIG guys had no reasoning when they wrote the guide lines, but often the zealot type users forget the original reasoning at all. And that it might not apply to all programs.

Looking at the HIG I found that it demands usage of the standard menus including the "File" menu. They say "The File menu contains commands that operate on the current document." And Liferea is not a document centric program. Therefore the "If your application does not operate on documents, name this item for the type of object it displays. For example, many games should have a Game instead of a File menu." exception applies.

Which is exactly what Liferea does. Damn... I hate to need to argue again and again on the same problem with the same argument.

Allan said...

Hey man: I feel your pain. Please don't take any of this the wrong way: you are doing a great job and we are all happily using it here.

If your application does not operate on documents, name this item for the type of object it displays.

I guess that is where people might feel uncomfortable. Liferea does not operate on 'programs'.

I completely understand that for your average document-centric application, the standard mixes document operations ('open', 'save', etc.) with global, program-level operations ('quit'/'exit'). I guess that whoever designed it felt that, as the saying goes, "consistency is the hobgoblin of little minds".

I guess Liferea works on three types of entities corresponding to the three panes: subscription lists, individual feeds, and feed items.

In the current layout, the first two are handled in the 'Feeds' menu item while the latter has its own 'Items'.

My suggestion would be to remove the 'Programs' menu, making 'Feeds' the first menu item. Feeds is kind of what Liferea is about.

Then you'd need to

1. Move the Work Offline and Quit menu items to the 'Feeds' menu, to have consistent inconsistency ;-) with the HCI.

2. Add a Tools menu for the Preferences, Update Monitor, and Script Manager.

That leaves the Edit menu. I think they are kind of confusing in three-pane layouts, but Thunderbird (for example) manages, so I guess as a lower priority it should be added.

I think that would make the menu structure easier for new people and essentially compliant with the guidelines.

(Being a hobgoblin myself, I might have gone for a three menu approach with 'Subscriptions', 'Feed', and 'Item' levels, but I really do not think it is a problem to combine the first two. Combining the two is probably a lot less work, and since we are not gaining an awful lot of functionality here, less work is good.)