Scott,
I really like the ability to see the match. That will make browsing the dial plan much easier. As you have experienced, trying to do it now, you mush know in your head what each one is doing. Mike From: [email protected] [mailto:[email protected]] On Behalf Of Scott Lawrence Sent: Tuesday, November 17, 2009 7:43 AM To: sipXecs developers Subject: [sipX-dev] Improved dial plan screen Having just helped a large customer to work through a bunch of dial plan issues, I have a set of suggestions for how we display them. I share them below to stimulate discussion... Here's a screen shot <http://sipx-wiki.calivia.com/images/f/fd/DialPlan.png> (posted to the wiki because it's too big for the list) taken from an HTML mockup I did (the colors are a bit odd due to interactions between my personal color preferences and the stylesheet): The improvements I'm suggesting are: 1. The internal and external rules are separated and ordered independently. This reflects how the rules really work - all rules that do not route to a gateway go in mappingrules.xml, and all that do route to a gateway go in fallbackrules.xml; each file is searched in order, mappingrules first - and fallbackrules is not used unless no other source of routing information (including aliases, registrations, mappingrules, etc) found a way to route the request. 2. I removed the Type column. Mostly, I did this to make room, but I also think that it has little value in helping to read and understand an existing dial plan. 3. I moved Schedule next to Enabled/Disabled because it reads more naturally that way than having it widely separated. 4. I added annotations to the Enabled column (could be somewhere else or a column by itself) whenever an earlier rule masks (matches) all or part of the same pattern: ⇑ when some numbers matched by this rule would be matched by an earlier rule ∅ when all numbers matched by this rule would be matched by an earlier rule (making this rule a no-op) with tooltips when you hover over those annotations that tell you which earlier rule(s) overlap. 5. I replaced Description (which says what the administrator thought the rule did) with three columns that display what it actually does: Match Displays any fixed digits and the number of variable digits matched by the rule. Send Displays how the user part (phone number, usually) is modified by the rule on output. To Displays what gateway (for external) or service (for internal) the rule sends the request to. The existing Descriptions are probably valuable, but I'd move them to a tooltip that displays if you hover over the Name, or something along that line.
_______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
