91588 - Ctrl+N in Composer should open new page

Status: RESOLVED WONTFIX

(SeaMonkey :: Composer, enhancement)

Description

[Blake Ross]

If I'm creating a website in Composer and I hit ctrl+N, I want a new blank page
-- because that's what happens in every other word processor and webpage creator
I know of.  In Word, if I hit Ctrl+N, I don't get a new PowerPoint slide; and if
the suite had a program whose name started with N, I wouldn't get that either. 
Global consistency throughout a suite just becomes silly when it starts to
impair usability.  Opening a new Navigator window should be Ctrl+Shift+N,
because that -- not a new blank page -- is the special case.

Comment 1

[timeless]

nice to hear what you want, but where's the npm.ui discussion?

Comment 2

[Charles Manske]

While I agree with you, I'm sure you know that the UE group feels consistency
across all modules is more important that 'what is logical' for a particular
app. You'll have to convince them on this issue.

Comment 3

[Blake Ross]

timeless: I'm not starting a newsgroup discussion about every change we make in
the UI.  Deal with it.

Since we have no one worrying about Composer's UI, German, can you please
elaborate on the rationale behind this decision, other than annoying consistency?

Comment 4

[Charles Manske]

Jennifer or German: What do you think about using "Accel+N" for new Composer 
page when in Composer? I'ver personally gotten used to Accel+Shift+N for new
Composer page, but Blake does have a good point.

Comment 5

[jglick]

I know German has been leaning toward the idea of using Ctrl+N to mean "New" 
(Nav/Msg/Blank Page/AB entry) in each of the main apps. I would be ok with it.  
The only concern is the legacy of previous versions.

Comment 6

[Charles Manske]

Attachment: Switch keybindings: Ctrl+N for new Composer, Ctrl+Shift+N for Navigator

Comment 7

[Charles Manske]

Note: I tried to use this:
  <menuitem id="menu_newNavigator" key="key_newNavigatorComposer" 
   observes="cmd_newNavigator"/>

for the New Navigator menuitem, to avoid having to duplicate the menuitem label
and accesskey strings, but when I did that, the accel key string "Ctrl+Shift+n"
was missing. Changing the ID so we don't share with globalOverlay menuitem fixes
that problem, but required us to have our own label strings.

Comment 8

[jglick]

Please allow German to comment before changing this.

Comment 9

[german]

Charlie: we are considering revamping the Menu this fall. Among other things we 
will be exploring an alternative to the File|New section such that ctrl-N would 
mean a "New whatever-app-you-are-in document". The current and 4.x philosophy 
is that certain accel keys have consistent meaning no matter which app you're 
in. This is a fundamental change and have to carefully look at not cutting off 
any previous and current users. To me it does not make sense changing it only 
for one app now, before we looked into this as a whole. Ctrl-Shift-N for 
Navigator in this context is also not great. By breaking it for one app you are 
essentially breaking the system across apps, which to me from a UI perspective 
is a worst case scenario.
I'd like you to hold off on that change for now if possible, and help me fold 
it into a larger menu redesign shortly.

Comment 10

[Charles Manske]

Sure, no problem. When you file a bug on the general issue, be sure to add
dependency on/to this one.
Are you planing on working on this issue for 0.9.4?

Comment 11

[Charles Manske]

This issue will be worked on after 0.9.4 - changing milestone

Comment 12

[Syd Logan]

spam composer change

Comment 13

[Charles Manske]

Jennifer: Any progess about changing the Ctrl+N assignments as part of more global 
changes as German implied?

Comment 14

[R.K.Aa.]

In the meanwhile.. "File -> New Composer Page" died.
(Ctrl+shift+N works, clicking icon on bottom works)
Current CVS Linux, but this isn't new. Couldn't find it filed, so mentioning.

Comment 15

[jglick]

Marlon's been trying to tackle some of German's stuff, but no, i don't believe 
any progress has been made on this one.

Comment 16

[marlon bishop]

German had made significant progress on the Menu redesign, since he's left it's
been in a proposal/draft stage.  It hasn't been finalized, but as he mentions in
earlier comments, it would be wise to still wait and implement this across the
entire system.  

Comment 17

[Charles Manske]

Seems like Lori should now decide this issue.

Comment 18

[Lori Kaplan]

The menu redesign is scheduled to be worked on for MachV but since it is low
risk and not a huge change it will happen after 0.9.8. I am currently working on
a prioritized list of specs and will post somewhere public so folks can see when
we'll get to things. Right now it looks like a few more weeks before we tackle
the menus. I think the cogent arguments are on tha table about the proposed
changed. We'll have to run a few scenarios to figure out which tradeoffs should
be made. If you need a decision right away, then don't change anything and keep
the current accelerators so the installed base doesn't have to relearn. They are
currently our target audience so we have to optimize for their usage. 

Comment 19

[Charles Manske]

Lori, Jennifer: Can we do this in Composer? Any more discussion needed?

Comment 20

[Lori Kaplan]

Charley, we still haven't gotten to the menu spec. It will be within the next
couple of weeks. That bug is targetted for 1.0. If you need to move on this one,
then I'd still recommend the same as I did before. If you can hold tight for a
little bit then we'll get it resolved soon. 

Comment 21

[Charles Manske]

More milestone load balancing

Comment 22

[Charles Manske]

The major consensus is to leave as is (accel+N launches Browser), but this issue
is still under discussion.

Comment 23

[Lori Kaplan]

We need to leave as is for the current release. The discussion can continue for
the future of course. 

Comment 24

[Charles Manske]

Some usability testing on this would be nice.
Do users prefer consistency across applications over the common
expectation that Ctrl+N opens a new page of current app.

Comment 25

[Syd Logan]

nsbeta1+ per buffy triage

Comment 26

[Samir Gehani]

Composer triage team: nsbeta1-

Comment 27

[jag (Peter Annema)]

-> me

Comment 28

[Pat Tressel]

May I disagree?  I've been lamenting for some time the fact that keyboard
shortcuts for navigation in the text area no longer work.  I frequently
forget this, and accidentally type ^N or ^D.  Then, instead of moving the
cursor to the next line, or deleting a character, I get to wait the minute
or two, with Composer completely frozen, while some window I didn't want
gets launched.

It's just not true that ^N is universally used to launch a new window.
Emacs doesn't.  This very text area I'm typing into in Bugzilla, to enter
this comment, provides Emacs-style keyboard shortcuts.  Earlier versions
of Composer did, too.

How about a compromise?  If the user has selected the text area, then don't
capture the control characters -- pass them to the text area and allow them
to be used for navigation in the text area.  If the text area is not selected,
then use the control characters for whatever you please.  If that was the
intent here, and ^N and friends are *supposed* to still provide shortcuts
when the text area is selected, and it's a bug that they don't do so, then I
apologize -- I wasn't able to find an existing bug report that made that
claim.

Comment 29

[Wayne Mery (:wsmwk)]

given the "new world order", is this a need to even one person still using the suite?

Comment 30

[Ian Neal]

Ctrl-N is New Browser window and Ctrl-Shift-N is New Composer Page in every other component within suite so switching them around in Composer would just be strange. Marking as WONTFIX