ticket type menu should be with other menus, or at least above "summary"

[xris <xris*siliconmechanics*com>]

For some reason, where it currently exists, it's very easy to skip over when filling out tickets. I notice that users, including myself, often forget to select the correct entry. Would be much more visible if it was above "summary" or at least down with the other menu options like "component" and "severity".

[cboos]

Yes, that's not the first time I hear this.
As it is now, the selection of the type can be overlooked.

Originally, the selection of the type was part of the title:

Create New Ticket of Type |....| (combobox with Defect/Enhancement?/etc.)

or even:

Create New |....| (combobox with Defect/Enhancement?/etc.)

IMO, the ticket type deserves special treatment.

[Chris Petersen <xris*siliconmechanics.com>]

Putting it in the title area is a good way to get it overlooked, too.

IMHO (as a coder who spends a LOT of time doing UI design), there are two good places (in order of preference):

1. Top of the page, above the username and summary
2. Top of properties, above priority

[Chris Petersen <xris*siliconmechanics.com>]

Any status on this? If someone pointed me at which files to edit, I could probably submit a patch.

[cboos]

The patch is not the problem.
The problem is getting some weight behind the change request,
otherwise it's more a matter of taste between the developers.

I'd suggest that you start a quick poll on the MailingList.
Then, if after some time there appear to be an agreement
in favor of this idea, I'll commit the patch.

Index: templates/newticket.cs
===================================================================
--- templates/newticket.cs	(revision 2746)
+++ templates/newticket.cs	(working copy)
@@ -15,16 +15,16 @@
   <label for="reporter">Your email or username:</label><br />
   <input type="text" id="reporter" name="reporter" size="40" value="<?cs
     var:newticket.reporter ?>" /><br />
+ </div><?cs
+ if:len(newticket.fields.type.options) ?>
+  <div class="field"><label for="type">Type:</label> <?cs
+   call:hdf_select(newticket.fields.type.options, 'type',
+                   newticket.type, 0) ?>
  </div>
  <div class="field">
   <label for="summary">Short summary:</label><br />
   <input id="summary" type="text" name="summary" size="80" value="<?cs
     var:newticket.summary ?>"/>
- </div><?cs
- if:len(newticket.fields.type.options) ?>
-  <div class="field"><label for="type">Type:</label> <?cs
-   call:hdf_select(newticket.fields.type.options, 'type',
-                   newticket.type, 0) ?>
   </div><?cs
  /if ?>
  <div class="field">

[cboos]

Having the Type: above the Summary: will also be consistent
with the changes in the Timeline, when we will display
Ticket #XYZ (defect: the thing doesn't work)

(see also #2070 and #2454)

[cboos]

Well, I still think this is important, but maybe we could
postpone this, after the WorkFlow merge. Also, I'd be interested
in Alec's opinion on the issue...

[athomas]

I also find myself skipping the type. Quite strange how the brain works :)

I think moving it is a good idea.

[cmlenz]

I think we should just move the field together with the other drop-down boxes, probably as the first item.

[cboos]

Well, I beg to differ... the whole TicketTypes thing was brought in the first place to have a way to talk directly about "Enhancement #XYZ" or "Defect #ZYX" instead of having always the generic (and a bit meaningless) "ticket" term.

In the future, we can think of having specific fields for different types of tickets (#2464), different workflows per type, etc.

So making the type field look like any other field goes exactly in the opposite direction.

I would suggest to have an interface like this for new tickets:

Type:             Short Summary:
 ---------- 
| Defect   |      ____________________________________________
 ----------

[cboos]

i.e. attachment:new_ticket_type+summary.png​

[cboos]

Ticket Type selector displayed left to the Short Summary, so that you can't miss it

[cboos]

The type selector is now placed with the other fields, since the ticket-preview merge.

[cboos]

(in r4986)