| Content of these pages are owned and copyrighted by the poster. | |
| Hosted by: |
|
MichaelD (Michael@javamail.every1.net) icq (60571661)
These agents should keep track of the users actions and offer help in various levels (full automation of tasks, interactive configuration of automatic tasks and so on). Agent technology is IMHO one of the technologies of the future, which will make the use of computers easier and comfortable (no, I don't mean assistants, i mean agents ;-))
The second thing I would like to see, is a proper speech interface to the GUI. Spoken orders should be executed in every situation. According to the experiences, which the agents made, the spoken orders could be executed immediatly or, if necessary, an agent could ask for doing this or that. Example: the order "Shutdown!" make sense on a plain desktop, or after minutes without any activity and the computer should shutdown. If a program was just started, the computer should ask for confirmation (in the traditional way, or per audio feedback).
Any comments?
this is just an idea. Please make suggestions, I will addin more stuff as I think more.
Now thats a good idea, but as for the mouse I suggest something a little less common, a surf ball. I forget where I read about it but it would be perfect for a 3D anything.
--DigiGod
I've always been interested in creating a virtual reality-based GUI as is being discussed here. I don't know Java just yet, but I plan to learn. Since this GUI will most likely be used by the advanced users, it should be highly configurable. The interface itself could be either a Java3D or a VRML world, with PROTO's of course, that link to files and commands. I think the user should be allowed to navigate around the interface, not be in just a confined area. Windows could be moved back and forth, rotated, resized, etc., and there should be a means to allow both easy navigation and the ablity to work with the applications while navigating. I have many ideas ... these are just a few of them.
--MikeHenry
Is anyone familiar with "the Brain" by NatrificialSoftware? This seems similar in concept to what has just been mentioned, but is somewhat lacking in implementation.
With a 3d implementation as the core, such an idea would be fantastic, especially if nodes (applications, documents, etc) were actually contained inside this world, as opposed to opened separately, inside a 2d JosDesktop.
The only problem with such a world is that it would have (or at least, be able to implement for slow machines) massive restrictions in the 3d world due to hardware constraints (for example, many programs such as games would not take kindly to real-time effects such as rotation).
For navigating files and program code, the class heirarchy (and most filesystems) seem(s) ideal for a virtual model as it slides nicely into the image of 3d corridors (com.bloggs naturally splits into com.bloggs.fred and com.bloggs.joe), however this causes a problem when someone wishes to use com.jos.jozilla.browser and microsofts.buggy.wordprocessor concurrently, or copy files from /a/b/c to /x/y/z.
--NathanJolly
As I recall, Xerox PARC did a bunch of work along these lines some years ago -- not so much a full 3-D environment, but 3-D widgets allowing comprehensible views of massive collections of data. The work was reported in CommunicationsOfTheACM perhaps ten years ago.
Might be worth a look at. Anybody know how this research has been going more recently?
--MikeMorris
Instead of an experimantal GUI being 3D, I think that we should look at what a computer really does for the user. In my opinion a computer stores data, dispays it, manipulates it and sends it onto another computer for manipulation. I use NT4 and think that all 10 billion ways of doing the same thing is rather extraneous. I think that the user should be presented with a standard way to access data and to manipulate it. It would be even more cutting edge I think if the user could type (or eventually speak) a command like "find me information about Java" and the computer would show the user a list of available data sourses all hyperlinked. This is just an idea and needs a lot of development, but I think really thinking about the role of a computer will drastically change GUI interfaces.
--BenByer
An additional use of computers is to augment the ability of humans to visualize. Currently, the ability of humans to mentally visualize, in three dimensions, is limited, except for a few gifted individuals. 3D imagery and animation could aid understanding and provide insights into concepts in electronics, physics and chemistry. CayteLindner RichardKeene
Haveing actualy played with and seen 3D GUIs I'll relate what they have been like.
First is the SGI 3D GUI objects. They have 3D buttons and such that rotate to show faces, etc. It looks cool and sells SGI hardware but is actualy not very usefull. It just burns up CPU cycles.
Second, when I used to work at Sun we had a 3D GUI in conjunction with head mounted displays. You could edit text on a shelltool floating in midair in front of you. Also very cool, but not 'better' than a regular screen.
I suggest that if we are talking about advanced GUI we instead focus on what can be done to improve the experience/productivity on a normal monitor.
This is going to be long, and partly reasoned out, and partly dogmatic. If you want the short version, the section "Summary" below does what you might think.
Reacting to a suggestion made above, the apparent explosion of interest in XML/XSS, and the points some pundits have made in favor in favor of "browser" and OS integration. ( note: I don't personally favor this, at least not with "browsers" working and looking the way they currently do -- however, certain ideas, like MIME, especially, should be 'back-ported' to the OS -- like windows 95 does w/ its "Registery" of file extensions and the like. Anyway... )
Many people have noted that the computer as an appliance is used for two main things, the first more advanced than the second: (a) storage & manipulation of data and (b) communication. This has shown up in (for instance) JOS's stated design goal of "built from the ground up to support the internet." and "Make cooperative efforts like this one easier."
Communication is mainly (ignoring the technical aspects of it) concerned with presentation ( to other people ). To some extent, people have realized this; however, the original promise of OLE, to be able to start the computer up with a blank document and never have the user need to know which application they were in, died rather quickly when Microsoft realized what this really would do: make software modular and hence, targetable by third-party vendors who, by concentrating on one audience or technical problem, could beat handily beat MS. (back to the point) For presentation, the "document-centric" view seems to be the way to go. This probably doesn't necesarily mean starting the user off with a blank page and the page-layout tools, though this is certainly a possibility. To make a presentation, (here we're moving into part (a)), one generally needs to do an analysis.
Right now, to do an analysis, one must choose the analysis tool and then the data. I would suggest -- as in object-oriented prorgramming -- that is more often than not more intuitive to choose the data and than the analysis tool(s). This, to many of you, may seem like an argument about applications rather than the OS... but here's two reasons to make an argument "about apps" here: first, apps make or break the OS. This is a given historical fact, so it needs to be considered. (Would Linux really exist without GNU tools?) Second, the OS's job is to manage the apps, so it's important to consider what those apps might be. Thirdly, the public image of JOS will depend on those apps...
( A brief aside before I continue on: it may be argued that people have been trained to think about tools they use for communication: i.e. the phone, the letter, the business meeting, the email app, the HTML editor, as opposed to the information they want to send... email, especially, is a major concern for the model I'm presenting because it is mostly reactive -- and any other reactive form of communication also has its pitfalls here. I'll try to address this below. )
How will users get to their data to begin the analysis? The answer (usually) is a search engine. (This might be consequent to really poor organization in the OS to date -- but I don't have real ideas to replace it, so...) A good search engine is a necessity -- and so therefore a good data organization is necessary to support that engine. Netscape and Mozilla.org have been making lots of noise about "interwingled" data recently, and the hard truth is that (a) it's true outside of the email app and (b) structural support for it is sadly lacking. The idea, I think, is so attractive, because of something about how the human mind works, but that's another argument for another time. Let it stand that it's good idea and that the OS must support some standard format for meta-data for the search engine to work on; perhaps XML. (let the technical debate begin!) However the XML is structured internally should be the presentation to the user ( probably) -- and like 'spin tables' in Excel, multi-axial (and selectable multi-axial) branching is probably a really good idea. IE: integrate date/version tracking along the z axis and the x and y axis being the 'normal' tree structure for folders and files. (refinement: only the files/directories in in the leaves of the tree are z-ordered, for better visual presentation.) Anyway, the Macintosh OS ( I know, I know! ) had some beginning of this along time back with the "resource" and "data" forks.
Argument: users don't like to create meta-data. Counter-argument: well, it's true; there's not much you can do about that except to automate as much of it as possible: especially in allowing arbitrarily long "file names" when the user "saves" a file. Also: 'full-text' or equivalent searches should be stored as meta-data against the files that are opened during the search, as part of the (usually empty) "keywords" entry. Why? The only things *I* tend to search full-text for are its keywords, and I'm sure the same holds true for the rest of you. This could be further refined by noting the breadth/depth of the search in which the keyword was made: "Civic" is probably more of a keyword in the context of "everything under "Honda" in the tree" than anywhere else. I have no idea about the technical problems associated with meta-data and its automated production; it's not an area I work with. Database / datafarm experts?
Anyway, the basic idea is that the user will ( in the presentation and analysis aspects of the "information appliance" ) want to start with the data and then apply tools to it. I'm not sure how (or if) it would work, but supposing the native file-format is XML, once the users has "opened" the desired data ( using the 3-D tree model, selected a subtree -- or several subtrees -- and dragged them onto the "workbench" ( == "desktop" ) ), the Beans registered to work with the particular data type ( as opposed to the beans that can handle that data type, i.e. the browser ) are brought up in the "toolbox" (the desktop icons change -- every (sub)set of data dragged onto the "workbench" for analysis (or selected and "moved" to a new workbench) gets its own "desktop" and theirs a meta-data-set thingy akin to the taskbar (w, of course, the infamous ALT-Fx shortcuts :)) The "default viewer" Bean (or if none, a selection of those Beans registed to that data-type and to its display) is used to display the data. Then, the 'active' XML data is passed through the bean -- either by dragging the data (or a subset) onto the bean's icon, or by (extending the icon into a toolbar) applying a tool to a data subset ( selectable w/ that tool). The bean passes the changed XML data back to the viewer, which updates the display (possibly in increments). The bean could also either spawn a window view of the data ( these tools would be spatially separated from the others ) ( and the viewer-only tools be a toolbar/box selection ). The data should be, as before, viewable by different axes; and in all cases, the user must be able to "save orientation" and return to a particular view later. For instance, looking at server uptime as a function of say, ambient temperature and corporate IT funding, switching the view to corporate funding as a function of annual preciptation and speculatively adjusting annual precipitaion and then returning. And so on; I'm sure database and spreadsheet freaks have good ideas here.
What about mono-dimensional data (i.e. raw text, sounds, movies )? To a certain extent, all data is mono-dimensionsal, (the most usual exception being that starts out as a spreadsheet, equation or database) -- it's the metadata (i.e. SSN is asociated with FullName) that makes the data multi-dimensional.) For mono-dimensional data, the problem with a relational OS (as I've been describing) is that the relations tend not to be explicit at all; it is difficult if not impossible for an automatic system to recognize that "Q1 financial report" ( for instance, from Powerpoint ) might have something to do with "Customer Satisfaction"... this is still an unresolved problem. On the other hand, things like filenames ( "titles" in the relational-speak ) are always characteristic, so it is possible to put mono-dimensional data into a relational system -- just not very useful most of the time. Again, meta-data (for now) has to come from the user. Important notes & exceptions: the information tree described above is by no means limited to the local HD. Other JOS systems on the local net can contribute their data (as security allows) to the "ubertree" of the LAN. Bandwidth permissions granted, ditto one LAN or WAN to another; and from the localnet to SQL servers and the like; and to human-made, but not user-made metadata in the form of directories like yahoo and netscapes's "what related". Every step farther in terms of speed and/or security should probably be confirmed by the user. as s/he traverses the tree. ( searches for information... is the tree is organized along the "java" axis, clicking on the little blue arrow at the end of the java axis extends the search to include say, the localnet, then the SQL server upstairs, and finally the xyz.com website/search engine -- the user can, of course, configure the order. Most textual data contains layout information. (i.e. MS word files) It should be possible to make use of this. Likewise, CD tracks (sounds less so) can be looked up to determine author and album and ordered that way.
If the user is creating new data right away, the blank document paradigm might not be a bad way to start; I don't have the foggiest idea what the default tools might be, but I'd suspect the user would change them pretty quickly; the idea of document templates here leads directly to the idea of tool templates -- suppose I want a new blank document that will probably end up being a program. In that case, I'd select the "CodeWarrior" tool template and be off. In this same way, companies can package their applications. MS office becomes a set of templates -- MS Word tool template, MS Excel tool template -- that share (XSS style -- which may or may not be the best way to handle this-- again, let the technical debates begin) the MS common tools template ( i.e. spellcheck, and "publish to web" ).
Since local storage is arragned relationally, saving incoming data (i.e. emails) in this arrangement is not difficult -- again, at the very least, title; if we've got cycles to burn, make the tentative_keywords_list based on the word repetition (excluding "the" and the like -- allow user filters here, too ).
You've probably noticed email is used a lot here. That's because it's nice and problematic, as well as absolutely essential to any OS. Email is problematic, as I've noted, because it's (one of the most common) reactive computer usages. (For now, even leaving aside the issue of if a user thinks "I want to send X an email" or "I want to send email to X" and how to support this two modes of thought... )
How does email work intuitively? (does it? how does any reactive process work intuitvely -- more on this in a bit) I use email in two ways, primarily: I both specifically check (at various times) if I've got mail, and leave something running to bother as to when I happen to have it. The second approach -- the more directly stimulus-respsonse one -- is trivial to fit into the scheme: a daemon thread waits around checking for email every so often. When it finds it, it creates a new (or uses an old one) workbench, where the 'active' data is the new email(s), and adds itself to the workbench list, beeping in some fashion at the user to let him/her know. Luckily, this approach lends itself to the first approach. By default, a user's workbenches are stored across sessions ( and there is some mechanism for storing them in a heirarchal way, like the start menu, where the beans in the workbench aren't serialized; i.e. everything is initialized instead of deserialized when the workbench is opened. (BTW: workbench needs a better name. "Desktop" is equivalent but decieving ) ) -- which means there is (should be) an "email workbench" that the user switches to when time or inclination permits. I would further expect that the reactive workbenches would be mostly data-display benches and relatively few tools.
(Note: there needs to be some simple way to change data without changing tools, and vice-versa, so that when I open my new mail and discover its MIME type is Excel, I can switch into Excel w/o thinking about it -- and vice versa, when I'm done with the brilliant Excel analysis, I can switch in the email toolset and send it off. The email toolset would (almost certainly) not display the anaylsis except notationally -- i.e. has paperclipped to the letter I'm writing -- and would start one off in the mostly-full screen email editor and the cursor in the "to" field.)
Note, pt2: the multiple-data same tool idea I mentioned above directly corresponds to MDI in Windows. The same-data multiple tool corresponds to nothing I'm familiar with. The screen layout in both cases, however, I visualize as very similar to Codewarrior -- the document in its own window, the toolbar/menubar (menucircle) around the edges -- not the document in its own window but directly on the "desktop". I expect the term "window" to become a notional one only soon -- whatever the bleeding-edge "window" manager equivalent might be might easily not look like windows at all.
Misc note: The browser technology, currently, is far more adept than the OS tecnology at information manipulation, though it takes, to some extent to the opposite approach, monolithically integrating capabilites into an enourmous binary. (The browser's ability to deal with hetergenous information is what makes it so attratctive as an OS...) The relative scarcity of plug-ins undermines that aspect of the browser; and the most succesful plug-ins are all also available as stand-alone apps. (Unless you consider applets and JavaScript plugins, but that's another story...)
Summary:
People and programmers have been using MDI and application-centric interfaces since the dawn of (computer) time. Recently, programming by objects has taken storm and led to (AFAIK) significant productivity increases. (For me, it has, at any rate.) The same needs to be applied to the OS/interface/apps. That OOP strategy is summarized as "Multiple Tools, Same Data" (MTSD) or, more directly contrasting the dominant MDI interface: "Multiple Tool Interface". Whatever logic lies behind browser/os integration stems from this recognition.
The information is the computer, not the network. Our objective must be to make the librarian lonely. Because we can't (yet) make a computer understand English, we can't make asking the computer as easy as asking the librarian: so we must make it faster and more able to help you use and transmit that information once you've found it.
If there's interest (please email me at tmiller@haverford.edu) I'll clean this up (expand it perhaps -- definitely offer me criticisms for further revision, please!) and post it on its own page as an essay on Expirimenatl UI design.
Just to begin, I don't have any OS or UI design experience, but being a regular user of many, I believe that I can accurately point out pro's and con's of any major UI. However, since this is an experimental UI project, I think the focus should be to get away from conventions like the 'desktop' theme.
My idea is this: the working environment is a sphere with a radius wide enough to provide that very little curvature is noticed in the viewing area. The workspace is infinitely scrollable in all directions such that no matter which way the user goes, he eventually gets back to where he started from. In order not to completely lose a project, small 'views' could be in each corner showing the workspace area and its contents from different 'camera angles.' The workspace itself is composed of different 'levels' of focus (anyone ever play that Tetris game for N64?) where the current project is pushed forward through nonlinear magnification (see http://www.cs.indiana.edu/hyplan/tkeahey/research/nlm/nlm.html ). This sort of layout gives the user more working area than would be convenient using 'virtual desktops.' If anyone would like to discuss or expound this idea further, please email me at sahib@earthling.netJoshua E Cook
One thing I would like to see is automatic installation of software using a local server. I imagine the following:
I get a Text-Dokument, it is in "JTextDoc"-Format. My Computer doesn´t know the JTextDoc-Format, so it asks my local server about it (or some Server on the Internet). My local server answers: Sure, I do know JTextDoc, you need the JTextEditor, which is 3 Megs in Size, do you want to install it? Or do you want to get the newest version of the Internet and install it?
I say, "Yes, please install it locally"... and after a short time, my JTextDoc opens.
MaxBerger (max-berger@usa.net)
| Content of these pages are owned and copyrighted by the poster. | |
| Hosted by: |
|