So, I recently saw some more updates on the Gnome Live wiki regarding the evolution of a ‘Semantic Desktop’. I have some bad news people: Its not going to happen. Now before everyone spends 20 minutes explaining all the ways it could, let me clarify my point. It’s a largely unattainable goal, which if it ever were to complete, would be a horrible user experience. I think somewhere between RDF, FoaF, and ObjectRank we lost sight of the original goal of a Semantic Desktop. We wanted to organize, present and store data in a fashion more congruent with the human mind. The general effort behind the Semantic Web and Desktop movements was to reduce the ‘multiplier effect’ of communication. (Take for example one e-mail sent to a mailing list, the file and data is now duplicated a hundred times over, and each receiver must filer or classify the e-mail with relationship to themselves). On the scale that communication takes place over the web, this effort is still crucial, but in the desktop world, where we operate on a billionth of the scale, that problem is not nearly as pervasive. No doubt the advances made in understanding and structuring the mass hysteria of the web will benefit desktop users, but I think forcing that structure onto the desktop is not only impossible, but counter-productive.
In my opinion the options are clearly laid out before us:
1) Move the desktop into the structured realm of a million and one tags/categories/color filters/labels/folders
- Or -
2) Get rid of it all. And just know what the user wants. (Ok, not really all of it, but instead of adding more hierarchies, we add more in-place understanding)
I know, its a bold statement, but somewhere between my tags, stars, labels, folders and emblems I realized that all these efforts we were making towards ease of use and understanding are just obfuscating things even further. These elaborate systems that require users to squeeze into sub-par standards like iCal exacerbate the problem even more, and ignore the efficiency of simple systems, like a pad of paper. (Yes, props to Tomboy). The problem is, many times a blunt-simple interface requires significantly more work on the programmers side (to actually understand the data entered) than a more traditional tabs-and-forms approach. I think we are demanding too much from users, how many people actually keep their address book completely updated? Or tag all their photos, or keep every document in the right folder? Even those who are vigilant eventually fall behind, and that’s because users already know what the material they are filling is, but still have to spend time explaining to the computer which items are related and where they belong. Especially for users with large sets of desktop data (Few thousand docs,e-mails,photos, and songs) the time can add up. Instead of asking users to commit even more time for data integrity and organization with more tagging systems.
The way I see it, we can count on 2 skills from a Desktop user.
1) Searching ( ThankYou Google!! Most people are quite comfortable with search phrasing!) or more accurately, knowing what they are looking for
2) To use their computer even when they aren’t looking for something (ie content generation, surfing the web, chat etc.)
These are the common denominators that we should be reaching for. We shouldn’t be trying to make the user classify their relationship with each person in their address book, we should just always be there, identifying the relationship based upon their level of interaction. And on a higher level than traditional approaches have taken us. After working on the Beagle Project for some time, the incredible weight of maintaining the backends to communicate with each mail client, each rss reader and each chat client almost seems to drown out the gain from having the data in a central and unified place. I mean, each time it was just someone talking to someone else right? Why have we taken simple actions and tried to codify them, when the complexities of human behavior are so great any Psychologist would tell you its a guessing game anyways. I think we should start with the disorganized mess that is someones workday at a computer and ask for nothing else. Reverse the system, take all of our analytical energies and structure, and use it for ourselves, in the backend, and just have the users use computers.
The best example of this is the phenomenon of tagging. Basically associating like objects via keyword-phrases. The problem is tags restrict themselves, lets say I have created a blog post about web browsers, while the tags ‘html, web, mozilla, ie’ may indeed be the most accurate 4 words from my point of view, they in no way approach the whole set of meanings and connotations carried by all their synonyms, let alone the entire post. In the realm of multimedia, tags are more useful, as images and videos are harder to extract contextual value from, but there is a better way….
Lets be smart! Instead of trying to stem the tide of data to make it more manageable, we ride the wave! Data is very rarely stagnate on a machine, people send photos to friends, edit each others papers, and share music all the time, there is a wealth of information in the chat I have with a friend while he listens to the new song I sent him, we just need to grab it!
I have specifics and even a little bit of code for my next post, but until then, I want feedback, do people agree? I mean, yeah, a million and one more ways for me to catalog and store my data, but when I’m actually looking for something the tags never seem to help much. While tags and folders do help with the clutter problem, I want to propose the idea that we move completely beyond presenting the hierarchy to the user, and start determining how (from the most basic of usage data) we could better present/organize information. Is the ubiquitous search box the only UI system that fits? What about something like Dasher meets lowfat, powered by an incredible datastore, but for files?
Tag Archive for 'Gnome'
So I just returned from my massive onslaught of travel that started with PyCon, took me from one US coast to the other, a Carribean island, and then back home to Washington D.C. I’m on Spring Break for the rest of the week, and hope to get some good blog posts in reguarding the awesomness that was PyCon 2008!
So I just finalized my registration for PyCon and booked my flight! I can’t even begin to express my excitement! If anyone else plans on attending, I made a wiki page for you to add your name to!
See you there!
Ok, I replaced our original autocomplete system with something a little more reserved, and based on a Gtk.Entry. Stealing heavily from a little-known F-Spot widget, I concocted a simple tagbar. Tab cycles through the completions and Enter selects. To give a rough idea of whats going on I made a quick screencast.
Let me know what you all think, if this is what we want to base our work on, then I’ll clear out the almost 500 lines of commented code from our past revisions. If we need to try something new, we can do that to.
Alright! Some cool news! The Mono Hackfest at the Novell OSTC in Provo, Utah was a success ( I would say, people showed up and we talked about features 
) And while I took several photos in the hope that I might have another photo-riffic blog post, but alas, my flash wasn’t on, and they are all pretty much worthless. That aside, it was pretty cool to root around more of the Novell OSTC campus.
As a by-product of the ‘Hack’ing portion of the hackfest, I am happy to report the enabling of tagging in Tomboy, while we are still working out the specifics of the tagging interface, a super-experimental version of our newest iteration (based somewhat strongly on the Blogger.com tagging interface which we all agreed was somewhat well designed). While this is mostly implemented, there are a few issues (mostly based on my lack of Gtk knowledge/experience) with some of the autocomplete logic. I basically created a new Gtk Window which is composed of a ListView and hovers over the entry area (actually a GtkTextView, as a GtkEntry wouldn’t handle text markup). There are 2 real problems at the moment.
- I need to handle keyboard input intelligently enough to allow selection of an autocomplete option, I just need someone more familiar with how keypress events are handled to take a look at my code and figure out what widgets I should listen to the keypress events on etc.
- I need to get the autocomplete popup widget to show in the right place (should be easy enough to get, again I just need someone a little more familiar with the Gtk API so I don’t spend another hour looking for the window positioning information.) and the widget needs to close when a note is closed. (Right now the autocomplete box hangs around, should again just be subscribing to a window destroy event, but my previous attempts have resulted in some messes.)
Anyways, if anyone has the time to offer a hand/check any of this out, just drop by #tomboy (I’ll be in and out due to exams, but I’ll do my best to answer any questions) or feel free to just fix it right off the bat Here’s a quick and dirty screenshot of the problem as it exists (you can see the autocomplete dropdown isn’t quite right).
In addition to traditional tags, we have added a new little tidbit for Addin Developers, the concept of System Tags. In short, any tag added to a Tomboy note with the system: prefix will not be displayed. While this seems a little stupid at first glance, this allows us to easily implement things like Tasks, and allow Addins to associate their own data with tags while not implementing their own data store, and still maintaining backwards compatibility. For example if I wanted to implement ‘Contacts’ in Tomboy (NOT A FEATURE THAT SHOULD BE IMPLEMENTED IMHO) I could simply add the following tags to store all the information I needed for my Addin:
- system:Contact
- system:FirstName:Kevin
- system:LastName:Kubasik
- system:EMail:KevinAtKubasikDotNet
And so on, anything with the ’system:’ prefix will be hidden from the user, but still stored with each note.
Well be hacking it up tonight at 6:00PM MST at the Novell Open Source Technology Center. The rough TODO for the night seems to be Tags, Tasks and maybe even a backend to query Beagle. ;) Anyways, if your in the greater Salt Lake City area, come on down! If your a little further away but want to join in anyways, join in on #tomboy!
See you tonight!
So, I’ve heard a lot of hype about the upcoming 1.2.6 release of Mono being faster, leaner, and more stable then ever before (due largely to Novell’s acquisition of a QA team dedicated to Mono). Beagle has always gotten flack over memory use, and as a result, we are relentless in our hunt for abused memory. And while it is wonderfully satisfying to reduce memory usage, its really hard to beat dropping megabytes of resident memory for free :). I’m running Ubuntu Gutsy and its 1.2.4 release of Mono, but in my quest for some real numbers to back up all this talk I built the current SVN trunk of Mono.
Even my most optimistic expectations put our potential benefit around maybe 2 or 3 MB resident less than beagle running under Mono 1.2.4. On my test setup, Beagle 0.3pre consumed (after my recent Opera backend fix) around 110 MB of VM and 36 MB of RSS (averaged over a 2 hour run).After building and installing Mono 1.2.6, the same 2 hour run was averaging 72 MB of VM and 27 MB of RSS! Its still far from perfect, but free memory reduction is just plain cool :).
Some observations about the general pattern of allocation and collection under 1.2.6, it ‘idles’ much lower than 1.2.4. While some actions always push the memory usage up, 1.2.6 *appeared* to return to its lower memory point much faster, and more regularly.
Anyways, I just wanted to say, props to everyone on the Mono team for rocking my socks.
It looks like the monster might finally start to lay itself to rest. After almost 2 years, one of the most basic feature requests for Banshee looks like it will finally be fulfilled. I’m talking about playlist syncing to iPods. While there have been a plethora of patches in varying states of readiness always floating around, it just never got into trunk. I am very pleased to have checked in a working (and building at the moment) patch which enables the management of iPod playlists though banshee.
I know that the patch has been in better shape, there were a dozen different times that a commit might have made sense, but in the end, ipod-sharp is a moving target, and trying to hit it and Banshee with stable API’s at the same time (without a freeze ) has proven to be quite difficult (no hard feelings to the Banshee dev’s they keep new features coming, and fast). Anyways, there are a few known bugs with this patch, most of which (in my super-limited testing) stem from ipod-sharp being in the middle of an API shift, and trunk isn’t working.
Anyways, I wanted to make a list of Features and Bugs, namely so the 2 don’t get confused, since a big part of this patch was trying to determine exactly what ‘expected behavior’ was, theres a lot of room to grow.
Known Bugs
- Major Performance Issues - This just needed to eventually go in, and maybe the new ipod-sharp api will have a better solution, but I started working on this, everything (meaning the entire music library) must be iterated over to find a corresponding track. Some preliminary work was done to get more content sorted/hashed, but theres still a lot of work to do here.
- Double Tracks on IPod - Depending on your version of ipod-sharp, and what random steps you take to get things building against your version, there is a common issue where a Playlist Dragged from the Library onto an iPod will result in duplicates of every song in the playlist on the iPod. This should be easy enough to track down if someone just has the time and patience.
- New ipod-sharp API - As there will eventually be a new ipod-sharp API, someone needs to migrate the current logic to the new API, should be mostly the same except for the device detection logic.
Behavior Issues/Features
- A Playlist from the Library to the iPod with the same name will result in the iPod version being overwritten.
- Dragging a track from the library to a iPod playlist will result in that track being copied to the iPod again
- Click and Drag support for playlist’s on iPod, its recommended that you drag songs from the iPod’s library
- Rename of iPod playlists
- Does not synchronize all library playlists to iPod automatically, only those which are placed onto the iPod
I think thats most of it, once iPod support in Banshee has leveled out a little bit, I plan on adding support for On-The-Go playlists and Smart Playlists. Anyways, I know that its far from a perfect commit, but after porting this patch through so many API changes, design shifts, and general bitrot, I really just wanted to get it out of Bugzilla.
The obligatory screenshot:
Note: I’ve tested this with the latest iPod Firmware, if you run the Hash tool as you normally would, it should work fine.
Today I checked in a few fun changes to Beagle today focused on the idea of emphasizing relationships between entities. It doesn’t sound like a whole lot of fun, but its kinda nifty.
New Query Context Options
- Find Documents by same author.
- Find E-mails from same contact.
- Find Pages from same site.
In addition (building upon Beagle’s new External Metadata system) I have added support for the tracking of Firefox downloads to files. The file downloaded with Firefox has an extra property (beagle:Origin) which denotes the Url it was downloaded from. I haven’t started to integrate anything on the UI side with this new information, as I want to add support for Epiphany, Opera, and Konqeror. Eventually, I would love to see this kind of mapping from downloaded mail attachments, but thats a little more difficult.
Anyways, this is more work towards my eventual goal of a ranking system based upon relationships (among desktop data). Anyways, I know that no feature-centric blog post is complete without screenshots, so I present:
Beagle’s powerful and simple query language makes stuff like this really easy, its just a matter of knowing what properties warrant special treatment like this. I’m open to ideas, what
I’ve been working on and off on a writeup concerning the use of Beagle to build an intelligent ‘rank’ for desktop entities. Or, in short, a Ranking system (not unlike Page Rank or the like) to organize desktop search results by far more than just keyword/date. I know the writing sucks, and its not 100% complete yet. In addition, I don’t have much in terms of code to share (yet).
To summarize (for those lazybones out there) I’m thinking of utilizing fairly universal and constant relationships (Creator, Creation Date, Modification Date(s), Parent/Source, and maybe others) to recurse deep into desktop relationships. By adding relevancy to the root hit for every child it has (logarithmically decreased by recurse iteration) we can have far more accurate desktop search results when querying a simple keyword/phrase. In addition, the children of a hit could often be considered hits themselves, if found in enough ‘root’ hits.
Its a loose and patchy idea, and miles from a realistic implementation, however, thanks to the awesomeness of Lucene, comparing 2 in-index documents for textual relevancy (based on Term Frequency) is not impossible. (I have not considered the performance elements of these comparisons yet, they may be too slow to be realistic without serious optimization)
Anyways, I’m working on it in Google Docs, so you can check out the full document here. I’ll post once I’ve finished my research/planning etc.
Please, share your thoughts! This is in the ‘major brainfart’ stage, so its open to whatever from anyone, I want to hear ideas!
Technorati Tags: beagle, desktop search, lucene, search rank, gnome, mono
Powered by ScribeFire.
Finally! Perhaps one of the last major features that Beagle needs to match Spotlight and Windows Live Search. Integration into every file choice made in the Gnome environment has long been a dream of mine, and a little less than a year ago, this bug was filed with hopes of making that dream a reality. After lots of hard work, a rough cut of the patch has been committed to the gtk+ trunk, with plans to add missing features in time.
While it will still be some time before this code reaches a Gtk+ release (development releases for the next major series start in late April) its great to feel some awesome love from our friends over at Gtk, a special thanks to Federico Mena Quintero for really being the driving force that finally got this done. What great is that plans for using Beagle’s index to help GtkFileChooser already seem underway.
For any budding Gtk+/Gnome/Beagle hackers out their, this feature still needs a lot of love. A list of bugs/todos exists here, and if someone were to get the ball rolling on anything on that list, it would be a huge help!
And last, the obligatory (if unexciting) Screenshots:
Here were searching for a Mail Attachment in Evolution.
And here we search for a file to upload in Epiphany:
Alright, before I get to the cool stuff, first things first, with current metadata system thriving, and at Beagle’s current speed, if someone really wants to start to stabilize up the Dashboard API a little more, and start to make this something less abstract, IM,Call, Mail (either one), or even just show up in Cleveland, and I’d be more than willing to help get Dashboard moving again.
Anyways, now that I’ve had another 2 minute excursion into the realm of getting Dashboard and its Banshee plugin building/working again, I have a quick 10 second screencast of dashboard being awesome.
http://qub333.googlepages.com/dashboard-banshee-plugin.ogg
The other cool technology that I really want to get integrated with Dashboard (or even Beagle) is the Open Natural Language Parser. In all honesty, there’s no way to describe how awesome it is until you see it in action.
http://qub333.googlepages.com/opennlp-sharp.ogg
Sorry I’m too lazy to convert and all that jazz, this is an impulse post that’s preventing work from getting done, so if someone wants to convert them, just let me know, I’ll host if you need.
So there’s been a lot of talk about a cool concept program coming out of the blur of Mugshot. While the exact goals of the project do seems a little more Web 2.0, the basic UI layout and goals seems to be remote services for something like Dashboard. Dashboard was the precursor to Beagle, (initially designed as an indexing and storage backed for Dashboard) and is basically a meta-clue processing center which brings up information relevant to whatever your are doing. The initial screenshots are extraordinarily old, but last summer during SoC, a complete redesign and recode took place, which is what can currently be found in the Google Code repo. While Dashboard is missing a lot of polish, I would recommend taking a look at its clue processing system, as its really quire ingenious, and the dream of every Beagle developer to eventually have to time to make it a real working solution again.
Anyways, I know its not the exact same, but its probably worth at lest a few minutes of playing time.
So the past few weeks have seen me getting more and more frustrated with the performance lockups in Feisty. As a developer who’s been running it for several months now, I can say I’m very tolerant and never upset, just try my best to help, mostly by just finding my own solution. So cruft and buildup is inevitable, lots of random libraries compiled out of the packaging system to get something working last minute, and I know my kernel is a wreck, as its seen more than a few major upgrades. However, when I started to read benchmarks where Feisty was taking a significant beating in startup times, I started to get concerned. I agree with the reasoning that dropping the heavily optimized kernels was a good idea, I had stopped using them a bit before, due to my own stability problems.
Anyways, this prompted me to make good use of my 500 GB external drive, and I am backing up everything as I speak, then doing an all-out optimization of my system with no regards to consequence (just for some numbers/fun ) and then installing the beta fresh (on a LVM’ed hard drive). I hope to have something of a comprehensive optimization guide for Ubuntu after this, but whats most likely going to happen is I get ansey for the new Feisty and LVM 
However, as I started my quest for a meaner and leaner Gnome/Ubuntu harmony, I trudged through the debates on prelinks, preloads, and readaheads (do what you will, nothing fantastic either way for me). But the first thing that truly changed my day to day desktop experience and in an incredibly positive way was Swiftfox. Its nothing revolutionary in terms of ideas, its just done well. Swiftfox really isn’t even a separate distribution of Firefox, its almost the exact same code, just with highly optimized releases for each processor. My initial thoughts were that it was going to be worthless, and maybe for your processor, it is, but with the Core Duo, its a world of difference. At first I assumed it was placebo, or something else I had done, but when my benchmarks showed no real differences anywhere else, Swiftfox outpaced Firefox, by a lot.
Just for fun, I have a few links below for rough web rendering performance benchmarks, make of them what you will, but let me say, drop your composting manager first, both beryl and compiz hated me when I tried, its too many rapid refreshes.
http://scragz.com/tech/mozilla/test-rendering-time
http://celtickane.com/projects/jsspeed.php
http://www.24fun.com/downloadcenter/benchjs/benchjs.html
Feel free to share your times, either way, I’m interested to know if this was a ‘My Firefox was so messed up’ or if Swiftfox is truly that awesome nerd inside that drives the speed of software.
Technorati Tags: mozilla, firefox, swiftfox, ubuntu, gnome, linux, optimize, speed
Powered by ScribeFire.
A follow up to my earlier post.
In my post last week I complained about how linux had no real torrent client that could go toe to toe with utorrent. Over the last week or so, I have been trying to follow up on all the awesome comments and suggestions that I got from readers. I found an answer.
Deluge is a Bittorrent client written in python and using libtorrent as a backend. Now, the release in Ubuntu Universe, and even its most recent 0.5 release were nothing to write home about, but the current SVN of Deluge shows serious promise. While I do *NOT* encourage users to try the SVN, as it is under active development (and I don’t want to force the project maintainer to answer a million questions about rapidly changing code) , I do feel that Deluge’s next release could match utorrent, or even surpass it! I found that while Deluge was taking a little longer to bootstrap less populated torrents, and the plugin/preference selection leaves something to be desired, Deluge is making huge progress in the speed area. Once I got torrents rolling, I found that Deluge was averaging about the same up and down as utorrent had been, and without the memory overhead of wine!
In short, I thank everyone for their awesome feedback, and thanks Deluge for stepping up and filling the niche for a full-featured and fast native linux client!
On a somewhat unrelated note, please consider filling out my survey on OpenID use if you haven’t already!
Recent Comments