Monday, December 29. 2008Context View, Reborn pt. 1
So as Nikolaj has been blogging about his cool new features that he has in store for Amarok 2.1, I feel obligated to reply. Can't let him steal all the thunder and PR!
Amarok 2 introduced many new features, and undoubtedly one of the most controversial ones was the context view. All of a sudden this large area was smack dab in the middle of Amarok, sticking its nose where some users didn't think it belonged. Mostly, this was because it was not always as easy or efficient to display data the data that users wanted, or it was clunky and hard to use. As the context view evolved alongside libplasma, some of the constructs that were used became outdated as well. All in all, the CV was not, in my opinion, living up to its potential and was very much one of the weaker spots of Amarok 2.0. What is to be done? Improve it, of course! Or, in this case, rethink the basic foundation of how the user interacts with the context view. There are two fundamental things that will be changing in the Context View that you will see in Amarok 2.1: 1) The Layout itself No longer will there be an idea of "containments, or "activities" (in plasma-speak). This idea, while quite nifty, didn't really work out great in practice, making it hard to manage a large number of applets and move them around. The new CV has a toolbar, almost a bit like the task manager applet for your KDE desktop. This will allow the user to visually see all the applets that are in the contextview, and instantly switch to any applet that he/she wishes to see. Basic screenshot:  Clicking on any of the applets in the toolbar instantly switches that applet to be the top-most applet. The applets after it are laid out directly underneath each consecutive applet. The little wrench icon that is visible switches between "edit mode" and normal mode. This is the edit mode:  Here the user can add new applets in any location, as well as remove applets. The user can also re-arrange the order of applets by dragging and dropping the toolbar representations. 2) The applets The fragmentation of data among the different applets provides for a lot of flexibility but not a lot of visual coherence. I personally envision a few select "meta-applets", that take up the whole CV at a time, but integrate data from multiple sources and lay it out in a coherent, simple, and space-efficient manner. So, a "web info" meta-applet would have wiki information, last.fm artist bios, lyrics, upcoming events for the artist, and maybe more. I do want to point out that these are very preliminary ideas that are still being fleshed out, and have not been fully reviewed nor accepted yet by the Amarok team. But with some luck Amarok 2.1 will have an awesomely solid CV that will be able to display much more information in a much saner form. 
Trackbacks
Trackback specific URI for this entry
No Trackbacks
Comments
Display comments as
(Linear | Threaded)
You were reading my mind. The next step: kill the sidebar and reimplement all four functions (collection, Internet, and the rest) as Plasmoids, and unify the side bar with the context view in a "Now Playing" configurable Plasma containment. That will do wonders for Amarok.
SO happy to be seeing this. I appreciate the effort in trying something new, but also appreciate the fact you can see it's flaws, even after putting in a lot of time.
The only issue I have with this idea is that it will contribute to the already incredible < - - wideness - - > of amarok 2.0, unless some kind of stacking is implemented along the bottom. I can use amarok 1.4 just perfectly on my media center which is hooked into my standard def 640x480 TV, but amarok 2 is far too squished to be usable whatsoever. I know that increased functionality might come at the expense of increased screen real estate, so we can't be expected to optimize everything for a standard def TV, but at the same time, there's no reason we have to assume this program should have to take up the the entire screen. The ability to hide the panes would complement this new CV very well and go a long way to making 2.1 great.
I really miss the applets being resizeable - will it be implemented also?
And I think it would be useful if the widgets could be dragged around by some top-bar or smth, like windows on desktop, but only on vertical means.
as i said above, this is a very early prototype. i've spend about 3 days on this so far. so if a feature is not there, do not assume that it will not exist. i probably haven't been able to add it yet.
that said, we are investigating different techniques for allowing the user to resize applets.
Sorry to swoop in with a random interface comment, but "Lyrics Applet" should probably just be labeled "Lyrics".
Looks great!
Now, one great feature would be to simply kill the left sidebar and reimplement that stuff as plasmoids. Then, for the now larger "context view", I'd envision a big switch (maybe at the top) between "Now playing" and "Browse Media" (terms of course to be discussed). "Now playing" would contain all the containments/plamoids of the current context view, while "Browse media" would contain the "collection" containment/plasmoid, the "services" containment, etc (everything that used to be in the sidebar). My reasoning behind this proposal is the following: 1) You rarely need to see the "now playing" stuff and your collection/services/.. at the same time: Either, I'm focussing on the currently playing song and information related to that, or I'm browsing for new media to play. By putting these two into the same screen area and switching between "Now Playing" and "Browse Media" by a big tab switch at the top we gain more useful screen space and also a less cluttered interface. 2) For me, the collection browser is currently a weak spot in Amarok. While the basic searchable tree is quite OK, I'd love to have more and different representations of my (addmittedly rather large, about 15000 songs) collection, e.g. the winamp-style 3-pane-view (artist | album filter on top, track table below) or a coverflow style album view. By making the collection browser just another plasmoid, it would be much much easier to create and integrate such new views of the collection. I would love to work on such a new collection plasmoid.
Oh, what I wanted to add is that such other representations of the collection (e.g. 3-pane-view or coverflow etc) don't really fit into a horizontally small sidebar, but would fit perfectly into the wider context view area.
And as stated in my original comment, when browsing through my collection, the context view is basically wasted screen space, as I'm not at all interested in the currently playing song and its lyrics while browsing through my collection (or through online services, for that matter). And while reading the playing song's lyrics or skimming its artist wikipedia page, I wouldn't be interested in seeing my collection at the left, I would more likely consider it as wasted screen space and added visual clutter/distraction. So: Let's kill the sidebar, and have a big fat switch between "Now Playing" and "Browse Media", both being containments in the context view.
For many of the services, adding the "service info" applet will actually show you context information about what you are currently browsing and not what is currently playing. Especially for Magnatune and Jamendo this is quite powerful.
This is something that will be expanded on and which is not possible with the old layout.
If the service browser would be integrated into a (much bigger) context view, there would probably be enough space to still display the information of the current service browser and the applet. I could imagine that this also leads to less visual clutter, as the browser and the context information are connected closer.
That reminds me of another question I had: What are the plans about context sensitive showing of applets? For example, reserving space to display information about services doesn't make sense when playing music from the local harddrive. Another example would be an applet showing the video part of music videos, which of course isn't needed most of the time.
wow! amarok really rocks again! there is one little thing i miss right now: the "remove duplicates and dead entries" option for the playlist.
I personally like the containments. If they could be renamed and the number customized I think they would be perfect. I really like the idea of having multiple different sets and layouts of applets. I guess containments are not necessary to do that but I really think some way to have multiple different context views that you can switch between at will is really important. Having to add and remove applets one-at-a-time when you want to change views is not feasible. I won't want to routinely completely reorganize my set of applets when I want to change views, I will set up 3 or more different context views and keep them that for a long time since I will (almost) always want the same sets of applets together.
The idea of having meta applets that contains the same information as several other applets may be good in some situations but in my opinion completely removes the main benefit of the new context view: customization. In KDE 1.x the several context views that were available were fixed, you were dependent on what someone else thought was a good layout. I really did not like how those views were set up. For me the current 2.0 context view is ideal since I can set up several different views exactly how I want them and switch between them at will. To me these meta-applets, based on your short description, seem to be a big step backwards, taking us back to the 1.4 days where I was forced to use the layout of "applets" (to use the modern terminology) that someone else thought was useful instead of the layout I want. So if you have meta-applets, they need to be user-controllable. And if you are going to do that, you might as well just stick with containments. Another advantage of containments is that they could, if programmed that way, allow task-oriented containment switching like they plan to do for the desktop. So for instance you can tell it to automatically switch to a certain containment when you hit the play button, automatically switch to another if a video starts, automatically switch to another when a media device starts. Being able to name your containments and then have them appear automatically when a particular event occurs would be extremely useful and increase the flexibility of the program immensely. If I recall 1.4 had the option to automatically switch to a certain context when a song started, this could allow a similar thing but have it be assigned to any context and any event. Containments can be combined with the new applet management scheme you are suggesting here. You would have a set of tabs or buttons for containments and then a set of buttons for applets. You could have it so one, or both, of the list is normally hidden until you mouse over a part of the context view or a button or something, or you could have them at opposite ends of the context view or one above the other. As a reply to the several people who suggested they combine the collection view and the context view, this may be good for some people but I have a wide screen monitor so having the three different areas is much better for me. However, I can understand how people might not like it. So I can see several other ways to resolve this. First, you could keep the collection browser but make it so it can be hidden and also make it an applet, so people can keep the current view or hide it and put it in the context view (perhaps as one of these meta-applets). Second, you can make it an applet completely but make it so the user can set whether her or she wants one context view or two. That way they can reproduce the current view by setting the applet on the left to be the collection browser and use the middle area like the original context view. They can also have just one context view and put the collection browser in that. They can also have the collection browser in the middle and the context view on the left. Yet another option would be to make the collection browser and the playlist be applets, and allow people to have one, two, or three different context views. That would be like the previous option except they can move everything everywhere, but it also makes things more complicated. These two options have the problem of allowing multiple playlists visible at once. However, if the playlists all actually display information on the same list of songs, so that changes to one changes all the others, it might actually be really useful since it would allow people to have multiple different playlists views handily available that they can customize and then switch between (that is, if you bring back containments so you can have one playlist setup per containment). I recall in the discussion of the new, more flexible playlist view someone asked to be able to have multiple preset playlist views he or she could switch between. This would allow that. It would have the added benefit of allowing two or more playlists to be placed next to each other, for instance having the new playlist and an amarok 1.4-style playlist side-by-side. Similarly, the current tabbed items in the collection browser (collection, playlists, internet, etc) could each be their own meta-applet, allowing you to set whichever of them you want wherever you want and switch between them by switching containments. I am not sure, however, that the applet system is flexible enough to handle having the playlist and/or collection browser as applets. This also seems to add a lot of complexity to the user, but it doesn't really have to since it can almost exactly duplicate the current layout. If you ship amarok 2 with a default layout roughly the same as it is, that is with a collection browser meta-applet on the left, a single playlist meta-applet on the right, and a good set of more traditional applets like "current track" and "recently played" in the center context view, you could have something simple and useful for less experienced users but extremely flexible for more advanced users. For instance currently you have to right click on the far left tab bar and uncheck a box to remove a collection browser tab you don't want. This way you just delete its containment or remove the applet and replace it with something else. That way there would be unified and consistent way of controlling the UI throughout the program, instead of the current way that will require two or three ways to do roughly the same thing (add or remove different sets of information or different ways to view the same information). It may be overkill a bit, but I personally think it would be very useful.
thanks for the comment
 to your point about meta-applets: this would not preclude you from being able to do what you can now. the architecture behind it is the same, so even though we would provide some meta-applets (in my vision that is, they dont exist yet) you would still be able to customize the CV with the applets that you wish (and the data that you want to see). your point about the "activities" is valid. however, my feeling is that for 95% of users it is a clunky and complicate system to use. the layouting is a bit wacky (including the sizing of the applets), the code is already complicated enough that it is a mess to try to even do small bugfixes. there is nothing stopping you from having different "virtual activities" with the toolbar, you can just click once to switch to the first applet of the bunch, and then all the applets that fit on the screen from that one on are visible at once, too.
Does this version of CV lend to something I wanted to implement (part of) as explained in this forum post ?
http://amarok.kde.org/forum/index.php/topic,13537.0.html
your long list of suggestions is all based on amarok 1.x, so they are not really portable to amarok2 directly.
if you mean the full-screen context view, that is most likely not going to happen. of course that doesn't mean it can't be done---with the new context view you could 1) write an applet that takes up the whole CV 2) hide the collection browser and the playlist and then you have a full-screen customizable area that can act like a set-top-box interface.
One of my thrust point was point #6 in the forum post where I wanted to customize one single CV to my liking.
• The whole square screen is divided into 4 parts (30%|70% up|down and 60%|40% left-right) with a nice looking cross showing this division • Top-Left part shows the song meta info extracted from anywhere, the media itself / web / lyrics file (in my example it would be from lyrics file eg.http://www.kde-apps.org/content/show.php?content=50890 - see screenshots) • Top-Right part shows the Album cover and other misc info • Bottom-Left part shows the lyrics - in my example show the lyrics part from the lyrics file • Bottom-Right part shows the rest of the info like Musicbrainz ratings, your scores in *****, other visual cues (should have minimal text in this box) • The whole pane floating on a semi-transparent, diagonally (TopLeft - BotRight) gradiated image of the album cover if present. • The bottom will have back/play/stop/forward and volume slider controls always visible.
yes you are most welcome to write the said applet. technically there is nothing stopping you
however, i hope you understand that amarok is not going to look like that by default
Applications really are just Activities; we just haven't started treating them like it yet.
|
Amarok LinksCalendar
QuicksearchCategoriesSyndicate This BlogBlog AdministrationWe Listen To... Powered by
|
||||||||||||||||||||||||||||||||||||||||||
