Changing the basics of a GUI
- salil_bhagurkar
- Member
- Posts: 261
- Joined: Mon Feb 19, 2007 10:40 am
- Location: India
Re: Changing the basics of a GUI
Well as I said, you don't do much with a small application. Its productivity after all. So if you don't have anything other to do, you might as well have the application fill your screen. If you need to do something with this small app and some other big app, you can adjust the scroll to accommodate more windows side by side.
Where users are concerned, its a completely new os. When you can get accustomed to 'ls' instead of 'dir' you can easily understand an intuitive GUI. Its the productivity and not the convention. When people can easily get used to the operating systems on their phones, why not this GUI.
Why do you think its suitable for phones and not PCs? Its just because thats how its been. Besides, most of the time, you double click the title bar of a window.
Where users are concerned, its a completely new os. When you can get accustomed to 'ls' instead of 'dir' you can easily understand an intuitive GUI. Its the productivity and not the convention. When people can easily get used to the operating systems on their phones, why not this GUI.
Why do you think its suitable for phones and not PCs? Its just because thats how its been. Besides, most of the time, you double click the title bar of a window.
Re: Changing the basics of a GUI
Out of curiosity what size/resolution screen do you use? I rarely maximise any windows on mine, because none of them need the whole space.salil_bhagurkar wrote:Why do you think its suitable for phones and not PCs? Its just because thats how its been. Besides, most of the time, you double click the title bar of a window.
In any case I think the only way to know whether it has any advantages over the traditional overlapping window system is to do user testing. As it turns out, most of the time, programmers aren't that good at creating intuitive/usable user interfaces.
The cake is a lie | rackbits.com
- salil_bhagurkar
- Member
- Posts: 261
- Joined: Mon Feb 19, 2007 10:40 am
- Location: India
Re: Changing the basics of a GUI
I use 1280x800.. But do you really put windows side by side and do inter-window work? IMHO what you mostly do is just switch between them by clicking on them even if they don't occupy the whole screen.
Another thing, I do not stress on a window filling the screen. The point is to have 1 window per screen normally. As i said, you can always have more, but not overlapping.
Another thing, I do not stress on a window filling the screen. The point is to have 1 window per screen normally. As i said, you can always have more, but not overlapping.
Re: Changing the basics of a GUI
I use 1280x1024. An clear example is VFD. It's windows is small (about 1/9 the screen) and unsizeable. Still provides great services.
Or, my mom - an accountant - ussually need to work with two or three Excel table at the same time. So she place them side by side, not full screen.
Or, my mom - an accountant - ussually need to work with two or three Excel table at the same time. So she place them side by side, not full screen.
"Programmers are tools for converting caffeine into code."
- salil_bhagurkar
- Member
- Posts: 261
- Joined: Mon Feb 19, 2007 10:40 am
- Location: India
Re: Changing the basics of a GUI
You never use VFD with anything. You mount/unmount and your done.quanganht wrote:I use 1280x1024. An clear example is VFD. It's windows is small (about 1/9 the screen) and unsizeable. Still provides great services.
Or, my mom - an accountant - ussually need to work with two or three Excel table at the same time. So she place them side by side, not full screen.
As I said ( ), your mom could roll the scroll to adjust the 2-3 excel tables side by side with full control over individual scalings in this GUI. Basically the full-screen functionality would always be default. You can always have multiple windows.
I think now i am thinking of making a 2-dimensional scrolling system where you could scroll windows over a 2-D matrix of programs. This could enable stacking of windows two.
And yes, your mom still doesn't use the overlapping aspect...
Re: Changing the basics of a GUI
You are right. I rarely use the overlapping windows in Windows. Most of the time I use full screen, or side by side. (Sometimes playing some small flash game while waiting for download to be ready). That is all. Programming is in full screen, testing not, but don't need rest of screen.
But, small applications will waste space. For a system meant to be used advanced (mix between supercomputer and personal, kinda perfect for me) is this ideal. May I use the concept?
I like it!
// PHP
But, small applications will waste space. For a system meant to be used advanced (mix between supercomputer and personal, kinda perfect for me) is this ideal. May I use the concept?
I like it!
// PHP
Jinix
Re: Changing the basics of a GUI
Kinda interrupting here, but I really don't see the OP proposing anything new. Current GUIs already support full-screen work (maximize button much), cascaded and tiled windows and scrolling between them (by means of a taskbar or a keyboard shortcut). In addition, they also support overlapping windows. I'd just like to remind people here that it's not about implementing something radical or different, but removing an aspect of what we perceive as a GUI.
Though preventing window overlap *does* reduce overhead in GUI programming, here are some things to consider:
- How would message boxes and applications with simple interfaces function optimally in variable desktop sizes? If you force an application or message box to expand to fill a variable screen, does it not sometimes damage the functionality or usability of that application? Though this could be solved by better design, applications that are inherently designed to be simple might struggle, and fill your screen with empty space.
- Furthermore, how would message boxes and alerts from the operating system or other applications work? Changing the focus to another virtual screen, resolving the message then having to scroll back to your previous application?
- Oh, and what about dialog boxes? Save as, open file, help, print, etc? Are you really planning on keeping each of these dialog boxes on their own virtual screens?
- Windows do (or did, at least) serve as some kind of abstraction in interface terms. Software such as GIMP and Visual Basic have or had traditionally use windows to abstract groups of functions and allowing the user to move them around the screen. If you didn't implement overlapping window functionality, aren't you forcing each and every application which wishes to use multiple "windows" on one screen to each create their own application-specific window system?
- And on a historical note, the Windows 1.0 GUI originally did not support overlapping windows. Due to consumer demand however, they eventually implemented it in subsequent versions of the OS.
Yes, I know the trend has been towards program interfaces based on movable modules or "views", where toolbars and sidebars are moved around and docked into different areas of the screen. (See Photoshop, Eclipse, Visual Studio, etc.). But the limitation is that other programs cannot be simply integrated into these program-restricted interfaces. In a way, current windowing systems help expand that metaphor into the GUI as a whole. And contrary to what some people have said, even though YOU may not use overlapping windows, that does not mean that no one else does. I admit, I don't use the functionality that often, but people do find it easier to be able to move windows around on a desktop to their own liking, instead of being restricted into GUI defined screen tiles.
The purpose of overlapping windows was always to keep true to the desktop metaphor. Personally, I don't believe in purposefully limiting users and applications merely due to convenience in programming. But then again, it's up to you. Nothing has stopped anyone from implementing a window system that successfully implements tiling windows and overlapping windows, right?
Just stuff for everyone here to think about. Wikipedia also has an article on tiling window systems, for anyone that's interested.
Though preventing window overlap *does* reduce overhead in GUI programming, here are some things to consider:
- How would message boxes and applications with simple interfaces function optimally in variable desktop sizes? If you force an application or message box to expand to fill a variable screen, does it not sometimes damage the functionality or usability of that application? Though this could be solved by better design, applications that are inherently designed to be simple might struggle, and fill your screen with empty space.
- Furthermore, how would message boxes and alerts from the operating system or other applications work? Changing the focus to another virtual screen, resolving the message then having to scroll back to your previous application?
- Oh, and what about dialog boxes? Save as, open file, help, print, etc? Are you really planning on keeping each of these dialog boxes on their own virtual screens?
- Windows do (or did, at least) serve as some kind of abstraction in interface terms. Software such as GIMP and Visual Basic have or had traditionally use windows to abstract groups of functions and allowing the user to move them around the screen. If you didn't implement overlapping window functionality, aren't you forcing each and every application which wishes to use multiple "windows" on one screen to each create their own application-specific window system?
- And on a historical note, the Windows 1.0 GUI originally did not support overlapping windows. Due to consumer demand however, they eventually implemented it in subsequent versions of the OS.
Yes, I know the trend has been towards program interfaces based on movable modules or "views", where toolbars and sidebars are moved around and docked into different areas of the screen. (See Photoshop, Eclipse, Visual Studio, etc.). But the limitation is that other programs cannot be simply integrated into these program-restricted interfaces. In a way, current windowing systems help expand that metaphor into the GUI as a whole. And contrary to what some people have said, even though YOU may not use overlapping windows, that does not mean that no one else does. I admit, I don't use the functionality that often, but people do find it easier to be able to move windows around on a desktop to their own liking, instead of being restricted into GUI defined screen tiles.
The purpose of overlapping windows was always to keep true to the desktop metaphor. Personally, I don't believe in purposefully limiting users and applications merely due to convenience in programming. But then again, it's up to you. Nothing has stopped anyone from implementing a window system that successfully implements tiling windows and overlapping windows, right?
Just stuff for everyone here to think about. Wikipedia also has an article on tiling window systems, for anyone that's interested.
"Sufficiently advanced stupidity is indistinguishable from malice."
Re: Changing the basics of a GUI
You may have a look at ion (http://modeemi.fi/~tuomov/ion/)
I tried ion as a desktop manager on a notebook some years ago. But at that time the choices of keys for desktop functions was horrible! And I did not bother to write my own configs.
I don't know how it is today, but the concept is what you are talking about, and what I myself think could be a better way then todays windows frames.
I think the critical part on a tilt bases system is how to make the learn curve as easy as possible.
ion is optimized for keyboard usage. So it could be useful on a mobile computer. But I think if you integrate the mouse correct it could be very very intuitive. Never the less you have to throw away the concepts that for example gimp is using. But in fact I don't like the gimp way. So I don'T care.
I tried ion as a desktop manager on a notebook some years ago. But at that time the choices of keys for desktop functions was horrible! And I did not bother to write my own configs.
I don't know how it is today, but the concept is what you are talking about, and what I myself think could be a better way then todays windows frames.
I think the critical part on a tilt bases system is how to make the learn curve as easy as possible.
ion is optimized for keyboard usage. So it could be useful on a mobile computer. But I think if you integrate the mouse correct it could be very very intuitive. Never the less you have to throw away the concepts that for example gimp is using. But in fact I don't like the gimp way. So I don'T care.
Re: Changing the basics of a GUI
If you want to actually do something new, you might take a stab at this: http://www.fat-man-collective.com/
Re: Changing the basics of a GUI
You don't understand. I mean she put them side by side together, not overlapping each other.salil_bhagurkar wrote: You never use VFD with anything. You mount/unmount and your done.
As I said ( ), your mom could roll the scroll to adjust the 2-3 excel tables side by side with full control over individual scalings in this GUI. Basically the full-screen functionality would always be default. You can always have multiple windows.
I think now i am thinking of making a 2-dimensional scrolling system where you could scroll windows over a 2-D matrix of programs. This could enable stacking of windows two.
And yes, your mom still doesn't use the overlapping aspect...
"Programmers are tools for converting caffeine into code."
-
- Member
- Posts: 2566
- Joined: Sun Jan 14, 2007 9:15 pm
- Libera.chat IRC: miselin
- Location: Sydney, Australia (I come from a land down under!)
- Contact:
Re: Changing the basics of a GUI
You don't understand. I mean she put them side by side together, not overlapping each other.
And...And yes, your mom still doesn't use the overlapping aspect...
I think it's a brilliant idea, and I hope to see how it works out! I'd suggest you try integrating it as a window manager for Linux or Windows first though, as a proof of conceptcould roll the scroll to adjust the 2-3 excel tables side by side with full control over individual scalings in this GUI.
Re: Changing the basics of a GUI
Yes, try Linux first (Windows, is that possible?)
About the dialogs, we can give each application there own window. The app can put their dialogs on that screen, and the user can switch between programs. So overlapping windows are possible only over there own app. That is how this problem can be solved.
But, why having open, save, save as, print dialogs, if we want a NEW GUI? The dialogs are old, and there should be other ways to do things like saving files. Like a windows moving in from the right, making main windows smaller. (it is NOT overlapping).
Just idea's upcoming in my head.
// PHP
About the dialogs, we can give each application there own window. The app can put their dialogs on that screen, and the user can switch between programs. So overlapping windows are possible only over there own app. That is how this problem can be solved.
But, why having open, save, save as, print dialogs, if we want a NEW GUI? The dialogs are old, and there should be other ways to do things like saving files. Like a windows moving in from the right, making main windows smaller. (it is NOT overlapping).
Just idea's upcoming in my head.
// PHP
Jinix
- Troy Martin
- Member
- Posts: 1686
- Joined: Fri Apr 18, 2008 4:40 pm
- Location: Langley, Vancouver, BC, Canada
- Contact:
Re: Changing the basics of a GUI
Sure, you just take a full-screen program and launch it at startup!PHPnerd wrote:(Windows, is that possible?)
-
- Member
- Posts: 2566
- Joined: Sun Jan 14, 2007 9:15 pm
- Libera.chat IRC: miselin
- Location: Sydney, Australia (I come from a land down under!)
- Contact:
Re: Changing the basics of a GUI
Backup and replace explorer.exe.
Just make sure you also provide a file manager of some description within your replacement
Just make sure you also provide a file manager of some description within your replacement
- Troy Martin
- Member
- Posts: 1686
- Joined: Fri Apr 18, 2008 4:40 pm
- Location: Langley, Vancouver, BC, Canada
- Contact:
Re: Changing the basics of a GUI
*wonders if the SHELL= line still works in vista....*