'Re: concept: action area in konqueror'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-usability
Subject:    Re: concept: action area in konqueror
From:       "Manuel Amador (Rudd-O)" <amadorm () usm ! edu ! ec>
Date:       2003-02-27 23:06:30
[Download RAW message or body]

Luke Chatburn wrote:

>Hi Manual...
>
>First of all, don't be so worried... I'm just hawking around a few ideas
>with intentional questions to move into other fields, so that it can provoke
>a few thoughts and questions about directions :)
>
And this is the great thing about mailing lists.  Had we not had the 
long threads we had (the IRS started to collect taxes on the word "had" 
just about now),this idea would have never come up, and we'd be at a 
loss.  This cross-pollination of ideas is one of the things I love the 
most about open source.

>We have two cases:
>1. In KFM: To display view-changing tasks
>
I get your point now.  Although I don't see the need for this, given 
that we have at least two other ways of invoking the same actions in 
this case - which is not true while previewing a file.

>2. In previews: To display view-changing tasks (zooming, etc.), options to
>carry out actions, such as 'Edit' and warnings ("This is a preview!").
>
I think we already have zoom in/out actions.  Perhaps we need to connect 
the slots where they correspond programmatically speaking.

>
>I'm just toying with a third case:
>3. Adding actions for filetypes when they are selected in KFM. This has
>advantages and drawbacks as Aaron said.
>
>Either way, if it is permanent, it takes up display space, and people may
>not like that, so we would need an option to add it or remove it. (Something
>to note, is that we are interested in the idea precisely because it has
>potential to congregate options of this type that users sometimes find hard
>to find!).
>
Which prompts us to the need of cleaning up menus.  Perhaps the edit 
menu needs a clean up to avoid us having to program *another* action 
access metaphor.

> The other option is to have it there by default and retractable,
>like the sidebar can be, essentially. It's a QSplitter job, and it is very
>simple to implement.
>
>Even if people want it, though, they will want to hide it sometimes for some
>tasks and bring it out for others, so it does have merits as a QSplit.
>
>I appreciate that people are aiming for the first two cases, but I think
>there are merits for using it for informational tasks (replacing some status
>bar functions, a DnD drop area, task help, etc.). I spend most of my time
>developing PHP-based dynamic db web sites, which are user-content heavy. A
>desktop environment is similar in that regard, since it is so user-data and
>activity-centric. However, there is great use in my web sites for adding
>spaces where static content can be added (help, info, etc.) and that allows
>a degree of user informing and channeling. Konqy in its many modes has a
>wonderful range of features, but the issue is that there are so many that
>some obvious and immediately useful actions are lost in the crowd, so to
>speak. The bar allows us to hand a list of actions (display options),
>meta-data and instructions to the user in a useful, contextual manner and
>say "Here... Take a look at these. They might be useful.". Windows XP failed
>in this, simply because the "Take a look at these" part got lost (was too
>small, non-graphical for the most part and in a bad position).
>
>We have a great range of features, but they exist waiting for the user to
>find them. Topics of discussion in recent times have been about how to
>effectively organise functions so that users have a far better chance of
>stumbling across them, putting them in the most intuitive places, so that
>they are there at the first place the user searches for. That said, putting
>LMB = open/action, MMB = Edit for KFM helps, and users will work that out,
>but it's still not as helpful as having a space to say "Double click to
>preview, middle-click to edit".
>
We still haven't addressed the thing about keyboard users and access to 
that window area.  They'd be served alright by the menus and context 
menus, but a good rule of thumb is that if something is visible and 
activatable upon, there has to be keybaord access. the GNOMErs are just 
about now discussiong how to provide keyboard access to Nautilus and 
GNOME toolbars.

>
>I'm rambling... Sorry. I just really wanted to get across the value of
>having a context-oriented action/display/information space.
>
>I'm just trying to spark some discussion, sorry if it was OT.
>
>-Luke
>
>----- Original Message -----
>From: "Manuel Amador (Rudd-O)" <amadorm@usm.edu.ec>
>To: <kde-usability@mail.kde.org>
>Sent: Thursday, February 27, 2003 8:52 PM
>Subject: Re: concept: action area in konqueror
>
>
>  
>
>>>How about if the bar pops up on right click with the context menu?
>>>
>>>      
>>>
>>defeats the hole purpose of the bar: be visible, notify the user the
>>file is just a PREview, and that he should choose one of the actions
>>just in case he wants to open the file.  for the bar to be useful, it
>>has to slide down or pop up every time you look at a preview.
>> preferably just to appear.  Or perhaps revert to a sidebar plugin like
>>the "Actions" plugin plus the file metainfo plugin, which would
>>automagically appear whenever a user previewed a file, and disappear
>>afterwards.
>>
>>    
>>
>>>If it is temporary, we're fine, since if it emerges over data (file
>>>      
>>>
>icons,
>  
>
>>>text, etc), it will vanish again. However, this does hide data. Like a
>>>      
>>>
>menu,
>  
>
>>>really. Doesn't take up screen space in a serious fashion.
>>>
>>>Alternatively, it might simply be a temporary QSplit at the top, thus not
>>>covering any data. This will move data though...
>>>
>>>If it is permanent, then it can be dragged up and down, I guess. QSplit
>>>      
>>>
>for
>  
>
>>>this. No data hiding in this case, but lost screen space unless the user
>>>hides it manually.
>>>
>>>      
>>>
>>perhaps there's no need to allow for resizeability.
>>perhaps the actions can be textually identical to the menu entries and
>>have icon sizes of the menus.
>>Perhaps the actions can be omitted, replacing them by a "Open the
>>Location menu for a list of actions" and you save yourself a whole lotta
>>programming.  Although this is a much simpler case than your action menu
>>system.  keep in mind all of the action your menu bar contains should
>>already be in the toolbar.
>>
>>    
>>
>>>:) Lots of random thoughts.
>>>
>>>-Luke
>>>
>>>----- Original Message -----
>>>From: "Luke Chatburn" <luke@linuxcomment.com>
>>>To: <kde-usability@mail.kde.org>
>>>Sent: Thursday, February 27, 2003 7:45 PM
>>>Subject: Re: concept: action area in konqueror
>>>
>>>
>>>
>>>
>>>      
>>>
>>>>Well, we can always make it drag-down like the sidebar drags out, or
>>>>drop-down like hiding the Kicker. :)
>>>>
>>>>To be honest, I don't think the loss of screen real estate is so
>>>>        
>>>>
>terrible,
>  
>
>>>>but as Aaron pointed out, it does rely on icon sizes, etc.
>>>>
>>>>-Luke
>>>>
>>>>----- Original Message -----
>>>>From: "Benoit Walter" <b.walter@free.fr>
>>>>To: <kde-usability@mail.kde.org>
>>>>Sent: Thursday, February 27, 2003 7:25 PM
>>>>Subject: Re: concept: action area in konqueror
>>>>
>>>>
>>>>
>>>>
>>>>        
>>>>
>>>>>Just kidding. Anyway I think you are probably right, the status bar, as
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>its
>>>>
>>>>
>>>>        
>>>>
>>>>>name says should only display information and we should not interact
>>>>>
>>>>>
>>>>>          
>>>>>
>>>with
>>>
>>>
>>>      
>>>
>>>>it.
>>>>
>>>>
>>>>        
>>>>
>>>>>Luke's solution is certainly the best one. It would be great if it were
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>only
>>>>
>>>>
>>>>        
>>>>
>>>>>displayed while previewing a document, and if it contained an
>>>>>
>>>>>
>>>>>          
>>>>>
>>>information
>>>
>>>
>>>      
>>>
>>>>>such as "Read only mode", or something that explicitely says that the
>>>>>document cannot be directly modified unless you open it with...
>>>>>
>>>>>Regards,
>>>>>Benoit.
>>>>>
>>>>>
>>>>>Am Thursday 27 February 2003 19:26 schrieb Manuel Amador (Rudd-O):
>>>>>
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>>>>I am very happy you have not said that was the most stupid idea on
>>>>>>>
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>earth
>>>>
>>>>
>>>>        
>>>>
>>>>>>>:-)
>>>>>>>
>>>>>>>Benoit.
>>>>>>>
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>haha.  I was really angry at my boss at that time.  Took it out on
>>>>>>unfairly chosen people.  sorry
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>>_______________________________________________
>>>>>kde-usability mailing list
>>>>>kde-usability@mail.kde.org
>>>>>http://mail.kde.org/mailman/listinfo/kde-usability
>>>>>
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>_______________________________________________
>>>>kde-usability mailing list
>>>>kde-usability@mail.kde.org
>>>>http://mail.kde.org/mailman/listinfo/kde-usability
>>>>
>>>>
>>>>
>>>>        
>>>>
>>>_______________________________________________
>>>kde-usability mailing list
>>>kde-usability@mail.kde.org
>>>http://mail.kde.org/mailman/listinfo/kde-usability
>>>
>>>
>>>      
>>>
>>_______________________________________________
>>kde-usability mailing list
>>kde-usability@mail.kde.org
>>http://mail.kde.org/mailman/listinfo/kde-usability
>>
>>    
>>
>
>_______________________________________________
>kde-usability mailing list
>kde-usability@mail.kde.org
>http://mail.kde.org/mailman/listinfo/kde-usability
>  
>

_______________________________________________
kde-usability mailing list
kde-usability@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-usability
[prev in list] [next in list] [prev in thread] [next in thread] 