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

List:       kde-usability
Subject:    Re: Create new?
From:       "Friedrich W. H.  Kossebau" <Friedrich.W.H () Kossebau ! de>
Date:       2003-07-19 13:14:30
[Download RAW message or body]

Am Samstag, 19. Juli 2003 11:39 schrieb Sander Devrieze:
> Op zaterdag 19 juli 2003 02:12, schreef Friedrich W. H. Kossebau:

<snip>

> > > 	File: [All things that really can store user input.]
> > > 		HTML (Web)
> > > 		Kivio (Flowchart & Diagram)
> > > 		KPresenter (Presentation)
> > > 		KSpread (Spread Sheet)
> > > 		Kugar Designer (Report)
> > > 		KWord (Document)
> > > 		Plain text [I renamed these because it isn't clear what's the
> > > difference between  "Text Document" and "Text File"]
> > > 		.... [Others can be added eventually]
> >
> > Where is this different from a "start app menu"??? I think here you throw
> > away an unexplored usability chance for the doc centric approach!!! Think
> > of the apps as tools to handle the doc or data you are about to create.
> > Be honest: When do you go for "New create.."? If you want to start an
> > app? Or create some new document? But see above.
>
> Agree 90%....I think many users will do Create->File:->appname to create a
> file on the desktop and they will directly after it open the new empty file
> in their application. 

Thanks for the screenies, now I understand that you want to change something 
on the "Create new..." menus :)
But: 
First I have to admit I feel a little guilty because when Sven Leiber did 
recently do the first changes to that menu (I think he was adding the 
additional menus for File, Device, and From Template) I emailed him privately 
saying how I would like to extend this menu when I have finished my actual 
project. I may not have explained in full depth how I would like to integrate 
KOffice templates, though. If this is still the old (copy template to 
directory, asking for new name, then exit) "Create new" behaviour (read: an 
according app is not started automatically) then he only did half of what I 
talked about (this is not meant as offense to Sven :)

So what I would like the "Create new..." menu (further called CNM) to be 
about:
* offers a broad set of templates, standard and hand made ones
* analog to the app starting menu the CNM can be edited and organised 
  like a user would like it to be (using the same virtual folder concept 
  so apps could easily throw in their default templates on install)
* an entry in the CNM could result in different actions:
  - old copy plain template and giving the new file a name^
  - a script running a dialog where one can set some parameters 
    then creating the new file by running sed on a template or 
    by creating it from scratch^^, and perhaps finally starting 
    a viewer/editor
  - a script running a dialog, starting the editing app in the background,
    (loading a template file) and hiding it until the user has completed 
    the dialog, then (DCOP-)scripting the app with the dialog's parameters
    and finally handing over the app's window to the user so he can
    manually proceed the editing
  - (forgot another idea, so anyone else?)
* given some more attributes to dirs there could even be different CNM 
  per dir^^^
* there may even be a favorite, last, and/or recently used templates list 
  at the top (like with the app menu)
* the CNM could deliver the actual selected files as a parameter to the script
  so some entries like "Compress" could be moved here

^ as a first step the "Edit new file name" dialog could be extended with a 
"Open" button.
^^ think of special inhouse ASCII based data format files as sometimes found 
in labs. I would have loved to have this feature when I was working at my 
diploma thesis.
^^^ in "bin" directory one will certainly create different files than in a 
"Documents" directory. The full CNM may still be reachable by a last entry in 
the special CNM.


Advantages:
* makes Konqui more usable as a shell 
* getting closer to doc centric approach
* less clicks, mouse navigation, and mind switching needed#
* faster using experience
* no fixed need for big bloated apps, but having small and simple scripts
* more possibilities to personalize/enhance your desktop

# What about this CNM entry: "Create new.../CD rip/Ogg vorbis format..."? One 
click, two mouse moves, editing some dialog and there you go (given the 
according script, cooperating e.g. with audiocd:/ ) 

> Some more ideas (from good to bad IMO):
> o Same as previous idea (no template selecting inside the menu) but don't
> start the application automatically. If people click on the new empty file
> their app will be started with the templates dialog popped up.

I guess it is very seldom that someone simply wants to create an empty file of 
whatever kind ;) I expect the usual workflow to be: "Hm, I need to write a 
business letter. Okay, let's create a new one. " So starting the editing app 
is very much possible and should not need further mouse actions.

> o Remove all the entries in the File (and Link to) menu(s). When clicking
> on File... (and Link to...) a dialog will be popped up which contains items
> very well ordened. (maybe you like this? :) )

No, I don't think there is a need to break the user interface experience. What 
is needed is a smarter layout of the menu items.

> o Remove all the template bloat in the menu but don't do other things.

Yes, let's remove the bloat in the template menu. But do some more things ;)

> > > 	Link to [resource?]... [All virtually things that not store user input
> > > except directory because this is used very often.]
> > > 		Application
> > > 		Camera
> > > 		CD-ROM
> > > 		CDWRITER
> > > 		DVD-ROM
> > > 		Floppy
> > > 		Hard Disc
> > > 		Location (URL)
> > > 		MO
> > > 		NFS
> > > 		ZIP
> >
> > IMHO this entries only make sense with the desktop. This would call for a
> > "create new"-menu-entries-on-an-per-dir-base approach.
>
> Why not? I can imagine if people like to have e.g. a directory on their
> desktop with URL's or devices inside.

But for most dirs this is just bloat. So that is why I would like to have a 
per-dir approach possibility.

> <snip old File from template idea>
>
> > If you had been with me right now you would have heard a big "Oh no!"
> > when I read this. I don't know how the "Create new.." menu looks in KDE's
> > CVS
>
> It's too overwhelming :)

Seeing the screenies I agree here. But I rather then throwing them away I 
would like to refine them :)

> > (failed to build as I lacked the disk space)
>
> I've putted screenshots of the menu in my Gallery with some explanations
> about what should be changed. See:
> http://devrieze.dyndns.org:3000/gallery/desktop_rmb_menu/desktop_menu
> (click on ">>" for next image or do a slideshow ;) If you like you can
> comment things.

Thanks. But going online by dial-in I appreciate answering by email ;)

> > but I know that I think the
> > "Create new..." could be of very much use than it is now. Especially
> > based on templates!
>
> Look first to the screenshots: it's too overwhelming :)

Yes, this has not been what I was thinking of. First I would not differ 
between "file" and "From template". Second there should be more submenus: 
e.g. with default KWord templates there would be submenus "cards and labels", 
"envelopes", "simple text", and "layouting". The page size should be moved 
into the creation dialog if possible as this is more a parameter. Remember: 
All I talk about here is my idea, based on theory not on how quickly this 
could be coded.

> > And by use of scripts and starting the according editing
> > apps:
> >
> > First, think about app starting times: What would it be like if you could
> > select "Create new.../Reports/Weekly...", get a dialog immediatly where
> > you could enter some data like main topic or whatever. While you are
> > entering these data the app (like KWord) is started in the background and
> > handed over the template when the app has finally loaded. Clicking Okay
> > on the dialog finally runs the associated script to fill in the dialog's
> > parameters.
>
> I think this example is already too advanced for the average user :)

Why? Because the traditional workflow is different, read app centric? I think 
my mum to have no problems with a more doc centric approach. She does not 
have to create the template (and script), there could be default ones 
(installed by the app) or special one mades by the sys admin (thinking of 
offices).

> > Faster user experience, less clicks. Maybe there even isn't any
> > further hand-made editing needed so the app is closed again right away,
> > leaving you with the final new file.
>
> Maybe you like my new second idea after reading it and seeing to the
> screenshots :D
>
> > Second, what about file templates not supported by an app?
>
> The app will simply be loaded then normally in my first idea :)
>
> > Think about
> > someone using plain editors for coding or latex editing.
>
> (The new kile (latex editing) will support templates :D )

But there may be users who like to stay with their plain editor for whatever 
reason. And there are formats no special editor is available for (like ehm, 
uh... ah: bash scripts or... well, if you think long enough, you will find 
some, at least inhouse data formats) 
And my idea is to have this templates additionally available _before_ starting 
an app so I would even like to have the app share it's templates with the 
CNM.

> > They could write
> > themselves scripts that would create a new header/source file doublette
> > or a new latex file with headers and the like, paramterized by some
> > dialog. All accessable by "Create new.../Programming/C++-class.." or
> > "Create new.../Latex/Section..."
> > There are some more things I have written down somewhere but can't access
> > it.
> >
> > Really, think about it, there is much unraised power in the "Create
> > new..." menus
>
> In CVS it's not intresting to have more power :D

Huh? What do you mean by this?

Friedrich

_______________________________________________
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]