Half a croissant, on a plate, with a sign in front of it saying '50c'
h a l f b a k e r y
A hive of inactivity

idea: add, search, annotate, link, view, overview, recent, by name, random

meta: news, help, about, links, report a problem

account: browse anonymously, or get an account and write.

user:
pass:
register,


                                                           

Interfacing Window-Pairs

Many are the times that one opens a pair of windows for a single reason.
  (+19, -1)(+19, -1)
(+19, -1)
  [vote for,
against]

A window, in a computer's Graphic User Interface, is a metaphorical device for being able to view items within a unit of storage - perhaps a drive, perhaps a folder, perhaps something else. In isolation, it's a pretty good idea.

However, it occurs to me that the actual usage of windows in an OS are often to be in pairs. Not all the time, of course - one might simply open a window in order to open an application, or a document. However, I think a significant portion of the usage is to open a window from some resource, in conjunction with opening another window from another resource - these then form a logical unit of pairing as far as the user's mode of use is concerned. Perhaps the user might want to copy or move something from one window to another - two common usages.

It occurred to me that two open windows by and large don't act as a unit, in contrast with what the user's action should be perceived as under normal circumstances. There should be a way of 'pairing windows' that denotes to the OS that 'these two windows have a relationship as far as the user is concerned at the present time'.

I think a good visual metaphor would be to allow a diagonal intersect to be drawn where these two windows might overlap. As soon as a pair of windows are 'paired' (explicitly - this won't happen by accident simply because they're near each other or overlap each other for some other reason) - then any overlapping area is actually a hindrance. When you're working with a pair of windows, if one corner of the top window obscures the lower one, it's actually getting in the way. One interesting side-effect of this diagonally interfaced pairing of two windows is that they're both 'on top' simultaneously, now.

In such a case, the window borders should be drawn as a diagonal line across the intersecting points of the horizontal and vertical edges of the window. One, maximal visibility of both windows of a pair is maintained. Two, it is visually apparent that the two windows are paired. Three, special operations can be perhaps engaged without the user having to go through quite so much pointing and clicking as presently, if the OS can offer a ready-made list of common paired-window tasks as usage patterns evolve into OS features.

Might also work for more than pairs. Not sure where it'll all end though.

Ian Tindale, Feb 02 2005

Panic.com http://www.panic.com/goods/index.php
A funky shopping cart system . [Jinbish, Feb 02 2005]

Artists impression http://tindale.dyn.nu/ibd/diagonal1.jpg
What it might look like - or perhaps not. Creating this highlighted several points that need solving. [Ian Tindale, Feb 02 2005]

Reshapeable_20Windows A part-way to implement this [DesertFox, Feb 02 2005]

2xExplorer http://netez.com/2xExplorer/
Dual pane file manager. No install. [tiromancer, Feb 03 2005]

[link]






       Finally! An idea worth reading in today's crop of shovelware postings. A good idea.
bristolz, Feb 02 2005
  

       Nice One.   

       In the same way you resize a window, there could be a tag that you drag open to reveal an imbedded window (with seperate address bar). This might work much like a tab system in browsers such as Firefox.   

       The website I've linked to has a shopping cart system that makes me imagine a paired-window system.
Jinbish, Feb 02 2005
  

       You must not work for Microsoft. This idea is more original than any of the changes I've seen from them in a while. Well done!
gardnertoo, Feb 02 2005
  

       I don't work at all. Can't find a job. One would be much appreciated though.
Ian Tindale, Feb 02 2005
  

       Uh, Rubic's™ Windows™?
reensure, Feb 02 2005
  

       My artists impression shows what I first imagined it to be like, but creating that highlighted several points that need addressing. First, scrollbars - although perhaps it's time for a rethink on scrollbars in general, occupying the entire span of an edge. Secondly, currently icons tend to cluster to top and left, given a default reign. One of the pair would be best reversing this tendency.
Ian Tindale, Feb 02 2005
  

       [+] good one. To build on it, it might be better that once you "pair" 2 windows, there's an interface bar between them (by default horizontal or vertical depending on "best fit"). You could then move or rotate this one bar and it would resize both windows accordingly.
sophocles, Feb 02 2005
  

       I posted an idea conserning reshapeable windows, lately.   

       If this idea is about making window's automatically reshape, it's redundant, except for the automatic part.   

       If it is about actually cyber-linking them as to be one program, then it is different.   

       See the link.
DesertFox, Feb 02 2005
  

       Yes, I'm now not sure that reshaping them is actually necessary to convey the concept of unified logical level of taskspace across two open windows. Especially if they're not even touching, which might make them seem too much like normal windows in such a case, and wouldn't be recognised if you're expecting a diagonal interface section to mean that two windows are paired now. So, the idea name has been edited.
Ian Tindale, Feb 02 2005
  

       Maybe the user could link the windows by dragging the mouse from an empty spot in Window #1 to an empty spot in Window #2.   

       I like [sophocles]'s "interface bar" idea. Since the two windows are related, common functions such as "Spill everything from Window 1 into Window 2" and "Complete Both Windows' Inventories Using Each Other's" could now be done with the click of a command button on the interface bar.   

       A thick blue line should suffice for indicating to the user that the windows are linked.   

       And as long as the windows are linked, minimizing one should minimize all of them, and ditto for making them visible again. Closing one closes all of them, and removes the link.
phundug, Feb 02 2005
  

       [DesertFox] This is much different than reshapeable windows. This is "paired" windows, which just seems so much more useful for me. No offense, but you have a lot of good ideas I like much better than "reshapeable windows".
sophocles, Feb 02 2005
  

       I, too, like the interface bar except when the two windows are far enough apart to not touch at all - or even have something else inbetween. What to do then? The solution should work both when the windows are distant, and when they're close or even overlapping, equally and similarly. It's quite a UI problem really.
Ian Tindale, Feb 02 2005
  

       Ahh, so the actually DO become cyber-linked, and in essence, one program/window.   

       I was a bit confused.
DesertFox, Feb 02 2005
  

       I like it. This would also help us migrate from the current reign of monolithic applications, to a world where everything was done with small single-purpose tools. The tools would be linked together as needed by UI means such as this.
krelnik, Feb 02 2005
  

       Maybe the problem of reshaping the windows could be solved by the placement of the interface bar - the region where the windows overlap could be taken up by an 'interface panel.' If the overlap region is not big enough, you could scroll it, perhaps.
Detly, Feb 03 2005
  

       I think desktops should have small pots of virtual glue, to be used to stick things like this together.
hippo, Feb 03 2005
  

       I like [Braubeaton]'s idea. Ian's illustration looks fantastic, but there are still problems with nonrectangular windows. Linked windows should behave much as normal windows except they should:
1)Come to the front, restore and minimise simultaneously.
2)Refuse to overlap.
3)Both open to fill half the screen (in a left/right configuration) when you click on 'Maximise'.
That would solve many of the operational problems without making too many big changes. You would probably need to add another window contol icon at the top of each window. Linking could be achieved by dragging the icon into another window.
wagster, Feb 03 2005
  

       // perhaps it's time for a rethink on scrollbars in general, occupying the entire span of an edge //   

       Agreed, begone with the scrollbar. Replace it with a scroll indicator, some subtle glyph pointing out 'there is more in this direction", perhaps » or some such.   

       But no more on-screen sliders. Scrolling itself should be relegated to the strict use of a tilt-wheel mouse.
waugsqueke, Feb 03 2005
  

       Not every computer has a scroll wheel... especially laptops. Obviously, they should, but they don't. And as nice as scroll wheels are, sometimes dragging the scroll bar is faster and more accurate.   

       Maybe, in some cases, the menu and toolbars can be merged, and either do to some edge of the screen, or sit on the border between the two windows?   

       I think this is something that needs to be worked out program by program though.
tiromancer, Feb 03 2005
  

       This is for the OS, rather than programs.
Ian Tindale, Feb 03 2005
  

       But should be callable as a service for apps, too.
bristolz, Feb 03 2005
  

       See also "Grouping windows by task" right here in this category (upper right) for a different idea aimed at the same problem.
krelnik, Feb 18 2005
  

       I like the triple-button mouse as a scrolling method. Click the middle button and then move the mouse to accellerate the window in the indicated direction (including diagonally). Even for computers without a triple-button mouse, it should be possible for some clever programmer to use a key combination for the same purpose.
supercat, Feb 18 2005
  

       With some of the work being done with X.org, this could probably be doable without a lot of work. The XShape protocol already exists to shape the windows any way they need to be, and a simple XSharedWindows (named to allow for more than two) protocol could control specifying windows' relations to one another. The most difficult part is actually going to be the application level support, especially getting it into all the main apps, such as konq and nautalis.
ironfroggy, Feb 18 2005
  

       I'm not conviced that this has anything greatly to do with applications. Apps seem to be able to do what they like, how they like, and once you're within an app, you're in a more or less bespoke representation of a working environment anyway - they don't work exactly like the finder does, as they represent a different problem space. The main instigation for this idea was the realisation that a lot of what a person does in the finder is in fact a collection of tasks that involve 'from' and 'to', or 'before' and 'after', or essentially, some state transition that also involves a spatial representation of that transition, and often on groupings of entities at once. The finder simply doesn't offer those tasks as part of the tool collection. It expects you to assemble the pseudo-environment and do the work yourself, each time. It fails to recognise that much work in the finder level falls into the category of a dual-ended process.
Ian Tindale, Feb 19 2005
  
      
[annotate]
  


 

back: main index

business  computer  culture  fashion  food  halfbakery  home  other  product  public  science  sport  vehicle