Thanks for the feedback. I have seen clips of Microsoft Surface. However, it doesn't look like it's targeted at replacing our working desktop. It seems like more of a social toy with a few useful features rather than a new user interface that will replace our current operating system. Though I'm sure Microsoft is looking at incorporating some of the ideas into Windows.
Well, realistically I need to sort all of my ideas into what's possible for a first release. For example, the visual database design kind of stuff will need to wait. My general plan is that at first it would be a Linux desktop. If it gains interest and as features are added it will make more sense and may even be necessary to make it its own distro. At some point in the far future there may come a time to make a commercial arm and really push it into everyone's lives, but that's just a dream at this point.
I kind of look at this project in terms of what applications/services can it replace and bring into your native desktop. So for the first Linux desktop release, I'd like to complete wrap around email, im, address books. Then there's the object hierarchy/ontology, spaces, tagging, etc and the scripts/tools standardization. I still have to work through the exact details of how the layers will interact.
Raster just replied:
basically you want us to re-implement every application in existence so it
works with your idea. you know that isnt going to happen? (from photo editor to
text editor and so on...)
Not every application. I think big apps always will have a place, e.g. 3D Studio Max, Music Mixing software, etc. I just think that many of the applications out there would be unnecessary if your computer was just more capable. It sort of ties into Tim Berners-Lee's talk on linked data. Why create brand new apps or websites around each data set? Why not just naturally access and manipulate the data with your computer? Use a collection of small tools that have uses if different contexts rather than one big tool that has just one useful domain.
It's exactly like the GNU command line tools. This time the command prompt is your desktop and each program can be executed through a discoverable interface rather than having to know the name of the tool. And just like GNU tools, you can install new tools and have them integrate with your desktop easily.
Think of why you use the command line and the power of piping programs together. This project would bring that kind of power to the average user in a visual form. Take grep for example. In this desktop, when you have muti-line text selected you'll have the option to filter lines. Under the hood the system will be using grep. It's just a matter of gluing everything together in a clever way.
I'm not naive enough to think I can do all of the work alone. But if I can just get a few developers to help design the core user-interface and concepts. The rest is just plugins and tools written to the standard. As these tools mature you'll bring them into the core set of tools that people will begin to expect from the system.
So for example: Somebody wants to watermark a bunch of pictures. This tool doesn't exist in the default system. They go to an online repository of tools and search for watermark and find something. The developer of this tool just had to think about an array of pixels and what parameters the tools has, such as the location of the watermark and the watermark image. After the user installs the plugin they can create a selection of images and use the tool to watermark them.
Think about the difference from the way its done today. Both the user and the developers job is easier! The developer didn't have to worry about designing a user-interface or a full-blown application. They just had to write a little script that adheres to a certain API. The user didn't have to learn a new user interface. More importantly they had to do less work in terms of clicks. The simplest application would require you to go through an open dialog or drag-drop pictures onto your watermarking app.
What's more is that combinations of plugins will increase the power of the other tools. So say in this situation I have 1000 pictures all in the same folder. Their names are a mess, and I only want to watermark a portion of them based on size. If I get a selection tool that lets me filter my selection of images based on size, then I just use the watermarking tool on that sub selection. With another authors image file filtering tool I've increased the power of the watermarking tool and any other image processing tool.
Again, in the current (old) model, you would have to rewrite your watermarking applicaiton to have image filtering features built-in.
I think it's possible, and more importantly, it's possible to do incrementally and distribute the work. The hard parts are creating a good API and standards for the tool plugins. Handling dependencies, API changes/upgrades, that kind of thing.
So as I see it, this system has two fundamental core components that would be independent standards:
1. The organization of objects, their properties, and how they can be accessed through an API. Classification of objects (simply mime-type?), inheritance of properties? How do you expose an object to a tool? How can ui tools search for objects and move them around (move between spaces, contexts, share them).
2. The tool standard. How you write a tool to plug into they system. Ideally you could write a tool in any language (C, Python, JavaScript, etc.) There's a lot of work in gluing the languages together. The API the tool has access to. For example, a tool working on an image would be interested in finding the image type, size, etc. The tool spec in terms of versioning, compatibility, dependencies, etc. Also, there would be different kinds of tools: object tools, ui tools, filter tools.
Then there's just the user interface built on top of these two standards. Your selection widget is just core tool. The selection widget listens for ctrl+clicks. When you ctrl+click something, the widget decides how to highlight it. Then it uses the previous APIs to query its objects, query the system tools, and match up the right tools for your selection. This means that if people don't like the way selections work in this system, you can just uninstall the default selection behavior and install someone elses widget.
In a way, the selection widget acts very much like a shell, executing other programs based on user interaction.
Hopefully I've made this idea seem more feasible.
No comments:
Post a Comment