"Just click the bad thing with the skull and it dies. Not only is it simple, it’s metal."
That comment about Grim Reaper Mode (also known as xkill) is part of some nice GNOME tweaks suggested here.
Also, Mirco has done some more nice videos, I read an interesting idea over here, although I think the idea is backwards, Firefox should not become the desktop, ie. making local and online applications behave the same by making the local ones look like, run like and generally be, shit like the online ones. I think getting rid of the browser as an application altogether and having web pages behave like local documents is a better idea (with bookmarks remaining behind after being finished with).
I've been experimenting with a little game idea I've had for years that I originally thought of doing in Flash (yes, I used to be evil too) but am now doing in Python thanks to Pygame and PyODE. I also think that making a nice Pygame IDE designed for simplicity would be a great idea, so I might start working on that (making it in Pygame of course!)
Saturday, 30 June 2007
Friday, 22 June 2007
Application naming
Yes, it is a sad day when the Free Software community is divided by issues such as application naming. Well, just to stir up a little crap I thought I'd give my (therefore, THE) answer to this "issue".
The problem of naming arises when names are made to be silly (like LINA, which stands for LINA Is Not an Acronym), or based upon previous names (like the name of the C++ language is based on the name of the C language (where C++ in the C language means "add one to C"), and the name C itself is one more than the name of its predecessor the B language, so called because it was developed at Bell Labs, or X.org, which is an implementation of the X windowing system, which is one more than the W windowing system which stands for Window) and thus describe their function in the world about as well as a grapefruit (WHY DO THEY EXIST?! Seriously, they tast SOOOO bad!).
The easy way of naming applications on a system is to use their names. However, with the names described above this creates a less than obvious setup for the uninitiated. The other camp seems to think that forgetting an application's actual name in favour of a description is more appropriate, often citing Microsoft products referred to as "Messenger", "Media Player", etc. However, I think this is wrong too.
I think applications should be allowed their own names, which should try to hold some relevance to the way they work if possible (but not doing so is forgivable if it is funny) like Inkscape draws as if with ink, GNUPaint draws as if with paint, etc. This should then be followed by the catagory of application they are, so GIMP Image Editor and Inkscape Image Editor. This way the purpose of the application is obvious, yet there is no kind of favouritism when competing applications are involved, eg. Microsoft can include "Media Player" in Windows because they only make one media playing application, whereas Free Software offers choice, so having Totem Movie Player and Gxine Movie Player is more preferable to any being called just Movie Player, since then users attempting to get support, for example, would be asking "The movie player won't play my video" which would start suggestions involving gstreamer, asking the user to click certain menu options, etc. After some frustration it could become apparent that by "the movie player" the user was actually using Gxine, which had arbitrarily been named Movie Player, and thus gstreamer plugins would not be of any help, and she would be asked to select menu entries which aren't there.
This system, already used by distros like Ubuntu (I can't be arsed to check any others), works because questions like "the image editor crashed" can be followed by "which image editor?" and the user can look and say "the GIMP image editor", or somebody recommending Free Software to a friend can say "I think the Inkscape Image Editor is the best one, because it lets you move lines around if they're not quite right".
OK, cleared that one up. NEXT!
The problem of naming arises when names are made to be silly (like LINA, which stands for LINA Is Not an Acronym), or based upon previous names (like the name of the C++ language is based on the name of the C language (where C++ in the C language means "add one to C"), and the name C itself is one more than the name of its predecessor the B language, so called because it was developed at Bell Labs, or X.org, which is an implementation of the X windowing system, which is one more than the W windowing system which stands for Window) and thus describe their function in the world about as well as a grapefruit (WHY DO THEY EXIST?! Seriously, they tast SOOOO bad!).
The easy way of naming applications on a system is to use their names. However, with the names described above this creates a less than obvious setup for the uninitiated. The other camp seems to think that forgetting an application's actual name in favour of a description is more appropriate, often citing Microsoft products referred to as "Messenger", "Media Player", etc. However, I think this is wrong too.
I think applications should be allowed their own names, which should try to hold some relevance to the way they work if possible (but not doing so is forgivable if it is funny) like Inkscape draws as if with ink, GNUPaint draws as if with paint, etc. This should then be followed by the catagory of application they are, so GIMP Image Editor and Inkscape Image Editor. This way the purpose of the application is obvious, yet there is no kind of favouritism when competing applications are involved, eg. Microsoft can include "Media Player" in Windows because they only make one media playing application, whereas Free Software offers choice, so having Totem Movie Player and Gxine Movie Player is more preferable to any being called just Movie Player, since then users attempting to get support, for example, would be asking "The movie player won't play my video" which would start suggestions involving gstreamer, asking the user to click certain menu options, etc. After some frustration it could become apparent that by "the movie player" the user was actually using Gxine, which had arbitrarily been named Movie Player, and thus gstreamer plugins would not be of any help, and she would be asked to select menu entries which aren't there.
This system, already used by distros like Ubuntu (I can't be arsed to check any others), works because questions like "the image editor crashed" can be followed by "which image editor?" and the user can look and say "the GIMP image editor", or somebody recommending Free Software to a friend can say "I think the Inkscape Image Editor is the best one, because it lets you move lines around if they're not quite right".
OK, cleared that one up. NEXT!
Thursday, 21 June 2007
Some interesting interface ideas
I have recently started musing about possible new ways of interacting with a computer. Of course, I do this a lot, but here are some ideas I have been pondering (when my programming improves I might be able to prototype these ideas for use in Warbuntu):
1) Tabbed interface.
Individual applications have tabs in them, the taskbar-style widgets usually running along the bottom of the screen are like tabs, so why not set the whole computer interface into a tabbed environment?
Every application would be fullscreen. There would be no floating windows so programs with such awful interfaces as recursive windowing systems (I mean YOU Photoshop!) would be avoided at all costs. Viewing multiple areas on the screen (like the GIMP's various dialogues) could be done via panes.
At the top of the screen there would be, right in the centre, the name of the current tab. The name would be editable, so files can be opened (using search), URLs can be visited (names would not be "Firefox - website name" they would be "http://www............" like in Sugar), programs can be launched, etc. Basically it would be like the GNOME deskbar.
Beside this there would be options for controlling the computer, like logout/shut down/restart/lock screen/etc.
Fork 1) Underneath this would be a universal toolbar. Like AmigasOS (sans MagicMenu) has one menu at the top (and this is used in OpenStep too so GNUStep uses it and apparently Apple MacOSX does too) but it would extend down to new, open, save, cut, copy, paste, etc. buttons. There would be a few catagories of these, each in named tabs (Office, Web, Graphics, Multimedia, etc.), so that graphics applications would work in the same way with the same toolbars, textual applications would work in the same way with the same toolbars, etc. These toplevel tabs would be the parents of the rest of the tabs.
Inside these, underneath their toolbar, would be the application tabs. These would be named after the application, so "Writer Word Processor", "Calc Spreadsheet", "Impress Presentation", "GIMP Image Editor", "Inkscape Image Editor", etc. this would follow a sane naming scheme which I will put in a seperate entry, since it has become too long here and deserves to stand alone incase later citation is desirable. Inside each of these would be the individal open files, the currently active file having its name in the top deskbar-type box (with metadata aligned to the right (or left in right-to-left languages of course) to allow files to have the same name and avoid messy hierarchical filesystems).
Fork 2) Use an arbitrary tabbing system, like current virtual desktops, where tabs can be arranged on a per-project type basis (ie. Having multiple webpage tabs available with click which contain information for a document being word processed. This would be possible in scenario 1 only for single tabs of each type, ie. switching to "Web" could show the previously looked-at webpage, but other pages would need 2 clicks, Web then the desired page). This would lose the universal toolbar idea, and could either use a toolbar in each application, or switch between standard toolbars.
The starting tab could be a list of common applications, and maybe even include little applets like the Mezzo desktop of SymphonyOS.
Various keyboard shortcuts could navigate the tabs (Ctrl+cursor keys and such), making this system very keyboard friendly, and thus very fast for those who know their way around a keyboard and who know the shortcuts.
2) Thumbnail file browser
After watching Macslow's little video demo I began to think how easy to use such an interface would be with a remote control. Direction buttons, along with perhaps some secondary up and down buttons (channel, volume, whatever) being used for page up/page down.
Images can obviously be given thumbnails in such a way, and therefore be easy to browse. Videos could be represented by thumbnails, and TV series or movies with a disturbing number of sequels could use a standard image, or if one is not available an arbitrary thumbnail from a video inside (which could be fast-forwarded or rewound by the user to get a recognisable image) to act like directories (with an Up or Back arrow image available inside any non-top-level directory). Music could be stored per album, with album covers for directories obviously, then the same inside with overlayed track numbers.
Of course, the idea of directories should be gotten rid of, so in a full computer environment, not limited by the limited input of a media centre style setup, this could be expanded. With gestures available via mouse, or better yet some kind of finger/physical pointing object (touchscreen, "Surface", whatever), the grid structure of elements can be disposed of. A BumpTop/Lowfat kind of file manager would be left, and I think the Lowfat way of pulling different objects together would be a good way of handling the "directory" issue, getting rid of any kind of hierarchy by making everything available on the same level, but capable of being organised or grouped. (Although I am not sure how objects in this single level would be grouped due to metadata, since a song can exist in catagories based on artist, genre, etc., but only when going through a multiple-level system (basically, narrowing down the current selection) so staying in one level there would have to be multiple instances of objects on display, which wouldn't be good news for confusion levels (unless some kind of overlay like translucent lines were used connecting the multiple instances of the same object)
I say "objects" rather than images, music, etc. as I think the idea of KDE4's Plasma and its "Plasmoids" is a good one, which is essentially that of making small, arbitrarily created applications movable around the workspace (I am on about the way it handles icons here, where icons representing files essentially become miniature representations of application instances (ever used an interface which Iconifies instead of Minimises, like RISCOS? Imagine every file icon actually being an iconified viewer application with that file open) To clarify what I mean, imagine dragging around an icon for a piece of audio (let's not use the term "file" here, as we are not bothered about the hardware implementation). Instead of having an audio playing application, which is fed pieces of audio, why not have play buttons embedded onto the icon? In that way the icon is no longer representing the audio so much as an instance of an audio player playing that audio. Using the grouping of Lowfat these could be made into playlists of audio and video, slideshows of images (although this is slightly less drastic, since images are represented by themselves, and thus a "slideshow" would just involve shuffling through the image objects), etc. Since applications aren't constrained to specific sizes or coordinates thanks to Metisse and more recently Compiz-Fusion, there is nothing stopping application "windows" becoming movable, rotatable, resizable (as in, proper resize, where it zooms in and out) icons.
Every piece of data would also have an Edit mode, which would just be a slightly more complicated version of the play instance, and thus the UI should be similar.
Ah, the tangents my mind is going off on tonight! The tabbed idea might be a solid base to work from to produce a consistent (and therefore slightly limited, but vastly easier) variation of what we already have, and that idea has been bouncing around for a while in the cavernous space behind my eyes. The second, however, is pretty newly formed, although has obviously been quietly swelling somewhere in my mind as the various links I gave added to it. Now the pan is boiling over and I am enjoying the sweet sweet flow of scalding milk that follows. What's more, it should appeal to the computer users that think a spinning OpenGL carousel of faces instantly makes a 2D list of users more "user friendly" (as in, bombard them with so much eyecandy they are too busy masturbating over it to notice how much their computers are costing). I'll try to make a Moho animation to visualise the crazy forks I am taking with this one. Ooo it's edgy!
PS: The service pack maker is coming along nicely, I'm learning Python pretty quickly. A few troubles with circular dependancy inclusion at the mo', but easily solvable if I use a global dependancy list, rather than a per-package one.
Tatty bye!
1) Tabbed interface.
Individual applications have tabs in them, the taskbar-style widgets usually running along the bottom of the screen are like tabs, so why not set the whole computer interface into a tabbed environment?
Every application would be fullscreen. There would be no floating windows so programs with such awful interfaces as recursive windowing systems (I mean YOU Photoshop!) would be avoided at all costs. Viewing multiple areas on the screen (like the GIMP's various dialogues) could be done via panes.
At the top of the screen there would be, right in the centre, the name of the current tab. The name would be editable, so files can be opened (using search), URLs can be visited (names would not be "Firefox - website name" they would be "http://www............" like in Sugar), programs can be launched, etc. Basically it would be like the GNOME deskbar.
Beside this there would be options for controlling the computer, like logout/shut down/restart/lock screen/etc.
Fork 1) Underneath this would be a universal toolbar. Like AmigasOS (sans MagicMenu) has one menu at the top (and this is used in OpenStep too so GNUStep uses it and apparently Apple MacOSX does too) but it would extend down to new, open, save, cut, copy, paste, etc. buttons. There would be a few catagories of these, each in named tabs (Office, Web, Graphics, Multimedia, etc.), so that graphics applications would work in the same way with the same toolbars, textual applications would work in the same way with the same toolbars, etc. These toplevel tabs would be the parents of the rest of the tabs.
Inside these, underneath their toolbar, would be the application tabs. These would be named after the application, so "Writer Word Processor", "Calc Spreadsheet", "Impress Presentation", "GIMP Image Editor", "Inkscape Image Editor", etc. this would follow a sane naming scheme which I will put in a seperate entry, since it has become too long here and deserves to stand alone incase later citation is desirable. Inside each of these would be the individal open files, the currently active file having its name in the top deskbar-type box (with metadata aligned to the right (or left in right-to-left languages of course) to allow files to have the same name and avoid messy hierarchical filesystems).
Fork 2) Use an arbitrary tabbing system, like current virtual desktops, where tabs can be arranged on a per-project type basis (ie. Having multiple webpage tabs available with click which contain information for a document being word processed. This would be possible in scenario 1 only for single tabs of each type, ie. switching to "Web" could show the previously looked-at webpage, but other pages would need 2 clicks, Web then the desired page). This would lose the universal toolbar idea, and could either use a toolbar in each application, or switch between standard toolbars.
The starting tab could be a list of common applications, and maybe even include little applets like the Mezzo desktop of SymphonyOS.
Various keyboard shortcuts could navigate the tabs (Ctrl+cursor keys and such), making this system very keyboard friendly, and thus very fast for those who know their way around a keyboard and who know the shortcuts.
2) Thumbnail file browser
After watching Macslow's little video demo I began to think how easy to use such an interface would be with a remote control. Direction buttons, along with perhaps some secondary up and down buttons (channel, volume, whatever) being used for page up/page down.
Images can obviously be given thumbnails in such a way, and therefore be easy to browse. Videos could be represented by thumbnails, and TV series or movies with a disturbing number of sequels could use a standard image, or if one is not available an arbitrary thumbnail from a video inside (which could be fast-forwarded or rewound by the user to get a recognisable image) to act like directories (with an Up or Back arrow image available inside any non-top-level directory). Music could be stored per album, with album covers for directories obviously, then the same inside with overlayed track numbers.
Of course, the idea of directories should be gotten rid of, so in a full computer environment, not limited by the limited input of a media centre style setup, this could be expanded. With gestures available via mouse, or better yet some kind of finger/physical pointing object (touchscreen, "Surface", whatever), the grid structure of elements can be disposed of. A BumpTop/Lowfat kind of file manager would be left, and I think the Lowfat way of pulling different objects together would be a good way of handling the "directory" issue, getting rid of any kind of hierarchy by making everything available on the same level, but capable of being organised or grouped. (Although I am not sure how objects in this single level would be grouped due to metadata, since a song can exist in catagories based on artist, genre, etc., but only when going through a multiple-level system (basically, narrowing down the current selection) so staying in one level there would have to be multiple instances of objects on display, which wouldn't be good news for confusion levels (unless some kind of overlay like translucent lines were used connecting the multiple instances of the same object)
I say "objects" rather than images, music, etc. as I think the idea of KDE4's Plasma and its "Plasmoids" is a good one, which is essentially that of making small, arbitrarily created applications movable around the workspace (I am on about the way it handles icons here, where icons representing files essentially become miniature representations of application instances (ever used an interface which Iconifies instead of Minimises, like RISCOS? Imagine every file icon actually being an iconified viewer application with that file open) To clarify what I mean, imagine dragging around an icon for a piece of audio (let's not use the term "file" here, as we are not bothered about the hardware implementation). Instead of having an audio playing application, which is fed pieces of audio, why not have play buttons embedded onto the icon? In that way the icon is no longer representing the audio so much as an instance of an audio player playing that audio. Using the grouping of Lowfat these could be made into playlists of audio and video, slideshows of images (although this is slightly less drastic, since images are represented by themselves, and thus a "slideshow" would just involve shuffling through the image objects), etc. Since applications aren't constrained to specific sizes or coordinates thanks to Metisse and more recently Compiz-Fusion, there is nothing stopping application "windows" becoming movable, rotatable, resizable (as in, proper resize, where it zooms in and out) icons.
Every piece of data would also have an Edit mode, which would just be a slightly more complicated version of the play instance, and thus the UI should be similar.
Ah, the tangents my mind is going off on tonight! The tabbed idea might be a solid base to work from to produce a consistent (and therefore slightly limited, but vastly easier) variation of what we already have, and that idea has been bouncing around for a while in the cavernous space behind my eyes. The second, however, is pretty newly formed, although has obviously been quietly swelling somewhere in my mind as the various links I gave added to it. Now the pan is boiling over and I am enjoying the sweet sweet flow of scalding milk that follows. What's more, it should appeal to the computer users that think a spinning OpenGL carousel of faces instantly makes a 2D list of users more "user friendly" (as in, bombard them with so much eyecandy they are too busy masturbating over it to notice how much their computers are costing). I'll try to make a Moho animation to visualise the crazy forks I am taking with this one. Ooo it's edgy!
PS: The service pack maker is coming along nicely, I'm learning Python pretty quickly. A few troubles with circular dependancy inclusion at the mo', but easily solvable if I use a global dependancy list, rather than a per-package one.
Tatty bye!
Subscribe to:
Posts (Atom)
