On Fri 12 Sep 2003 06:20, Don Pobanz wrote:
So, focusing only on the tree structure, what should
the> menus look like?
>
> Attached is a rough draft of what it may look like.
>
I have added some specific comments on this proposal, enclosed with //// for
lack of a better idea since most other symbols are in use already. Some of
my criticisms are with commands that I used in my own implementation, so I
don't feel too bad making them.
Cheers,
Brad
State A - in voicemail listening to vm greeting
[*] cancel leaving a message (system waiting for input) (NEW) (see state D)
[0] to reach operator (as defined in extensions.conf) (no message is left in
vm)
[#] if listening to greeting, skips rest of greeting and jumps to recording
message
[#] - if recording a message ends recording
[*] - Cancel message (erase recording) (gets message please rerecord your
message)
//// This would be the same functionality as [3] erase & re-record; more
reasonable would be to either:
a) cancel this message entirely and ask for another mailbox number to leave a
message for
b) cancel recording this message and offer some options like:
i) record a message for this person
ii) reach operator
iii) record message for someone else
iv) log into a mailbox ////
[1] - Accept recording
[2] - Review (listen to) recording
[3] - Erase and re-record
[0] - Reach operator (as defined in extensions.conf) (no message is left)
//// In the case where you press 0 here, it's debatable whether the message
should be retained or deleted, since it was after all recorded
Also useful in this state would be a way to get from the outgoing greeting to
a log-in prompt. In my patch, I used 9, since * and # are taken. Alternatives
are:
a) Use * to cancel recording then give more options including * or # or
something to log in;
b) Use * to cancel recording, or ** to log in. ////
State B - in vm as a vm box owner. System has associated vm box (maybe based
on caller ID).
[*] - cancel asking for password (see state D)
[#] - tell system password of null has been entered.
//// Would this get you anything other than an incorrect password message?
////
[password] (times out after few seconds of inactivity or upon pressing
'#'
key)
[0] greetings mailbox options
[1] record unavailable message
[2] record busy message
[3] record name
[4] change password
[5] temporary greeting
[1] - Listen to greeting
[2] - Re-record greeting
[3] - Set expiration date
... [1] - Expires at midnight tonight
... [2] - Expires at midnight tomorrow
... [3] - Expires some other time
... [*] - Never expires
[4] - Delete greeting
//// Note that greetings on 1, 2, and 5 is not terrific. Better choices would
be:
a) greetings on 1 (unavailable), 2 (busy), and 3 (temporary)
b) greetings on 1, then 1 (unavailable), 2 (busy), 3 (temporary), * cancel
greetings
////
[*] cancel - return main menu
[1] new message
[1] listen to first message
//// What is the point of pressing 1 twice? In other words, what other option
do you have after you have pressed 1 the first time? ////
[1] back up and repeat last 3 seconds (NEW)
//// Currently, this is on *, and fast forward is on #. If * and # are adopted
as standards for going forward/back, those might be more logical choices. On
the other hand, because 4 and 6 currently are used for previous and next
message, an alternative could be:
4 - rewind
6 - fast forward
# - end playback of this message
* - stop (pause maybe) playback of this message
It would be nice to have a 1-button command to stop playing of a message, so
that you could get to listen to your options without listening to the entire
message or without fast-forwarding a whole bunch of times. ////
[11] restart message (NEW)
//// This would be the same as the current 5 used to repeat a message.
Implemented this way, 11 would be needed to repeat during playback, and 5
aftwards. Currently, also, once playback of messages has begun, pressing 1
goes back to the first message in the mailbox. An alternative to that, which
would make better use of keys and free 5 for another use, would be
1 - Play messages (before playback has begun)
1 - Replay current messages (once playback has begun)
4 - Go back to previous message
44 - Go back to first message ////
[2] pause message (NEW)
[3] skip 3 seconds of message (NEW)
[33] jump to end of message (NEW)
//// Again, if # is always to mean jump to end.... ////
[4] slow down the playing of message (NEW)
[5] Get envelope information about message (NEW)
[6] speed up the playing of message (NEW)
//// Currently, 4 and 6 have valuable uses during message playback
(previous/next) that are not replicated anywhere in this scheme. This new
implementation would require 337 or 339 to skip to the next message while
deleting or saving, respectively, and I don't think it offers any way to get
to the previous message, or a way to get to the next message without taking
some specific action.
Also there is no functionality currently that would slow/speed up the playback
of a message. ////
[7] delete message
[2] (REMOVE change to different folder for this option for this part
of tree)
[3] advanced options
[1] - Reply
[2] - Call sender
[3] - Hear message envelope - reads CID number and date/time when
message was left
[4] - Place outgoing call
[5] - Compose message
//// Grouping these commands together, and leaving forward as a single digit
command on 8 does not make sense. There is really no reason that reply,
callback, and forward should be on a different level from other message
options. The only alternatives to achieve that would be making some crazy
re-arrangement of keys, like
2 - reply
3 - callback
5 - envelope
8 - forward
and shifting the existing commands 2 (folders) and 3 (advanced options) to
being accessible only from the main menu, and making 5 (replay) into 1
(replay)
or,
Using 2-digit commands, like
81 - reply
82 - callback
83 - forward
etc. ////
[*] - Quit advanced options
[4]
//// Currently, 4 is previous mesage ////
[5] repeat message
[6]
//// Currently, 6 is next message. I realize that the functionality is similar
to save, but if you press 9 to save, you have to go through selecting a
folder to save to, and if you just want to browse quickly, it is not as
handy. ////
[7] delete message
[8] forward message to another user
[9] save message
[*] exit (NEW)
//// Where would help go? Well, 0 might be a good choice. ////
[0] mailbox options - plays menu of options
//// Although I don't necessarily favour the tree-type structure, if 2
(folders) is going to be removed from this part of the tree, for consistency,
0 (options) would also have to be removed and made accessible only from the
main menu. Then again, the tree structure would allow for more numbers to be
assigned to more things, message options could go on 5 or something in the
main menu, and 0 could get you help, and 00 the operator, or something. ////
[#] exit (NEW remove exit)
//// At the very least, I would like to see exit not share a key with fast
forward or anything else that might get pressed accidentally ////
[2] change folders
[0] to new messages folder
[1] to old messages folder
[2] to work messages folder
[3] to family messages folder
[4] to friends messages folder
[#] cancel
[*] cancel (NEW)
[3] for advanced options:
[1] - Reply
[2] - Call sender
[3] - Hear message envelope; reads CID # (or recorded name if CID
corresponds to a mailbox number) and date/time message was left
[4] - Place outgoing call
[5] - Compose message
[*] - Quit advanced options
//// Again, mixing advanced commands related to specific messages and other
general advanced commands into a submenu makes no sense. Taking the group of
general commands here (compose and outgoing call), the question would be
whether they should be part of a tree that is accessed on 3, or whether they
should be 2-digit commands that start with 3. ////
State C - in vm as a vm box owner. System does not have an associated vm box.
[*] - cancels asking for extension. (see State D)
[extension number] enter the vm box (as owner not to leave message)
(asking for password - see state B)
State D - in vm bottom directory - waiting for input
[*] exit voicemail
[#] tell voice mail you are a voice mailbox owner
//// Why would you use # (assuming * is your cancel button) when the system is
asking for a mailbox number to leave a message, and what you want to do is
cancel that and log in? Also, below, if you want to go from the password
prompt to the mailbox login prompt by pressing *, wouldn't it make more
sense
if the button to press to get to the mailbox login prompt were the same in
both cases? ////
[*] back out of being voicemail box owner (see State D)
[extension] tell which extension. VM now has an associated mailbox.
(see state B)
[extention] enter an extension to leave a message