Oopsie, I neglected to see the limit of 5 in Scott's original post. Sorry for the overload yesterday.
Todd Hodgen wrote: > Nice Idea Scott, thanks for this opportunity for all of us to help shape the > future features of the product. > > Things that I would like to see put into the product that makes it easier > for users, admins, technicians, etc. are below. I numbered them 1-5 so I > don't go over my limit like Picher did, but you may find more than one idea > under each number, so I am a being a hog - like Picher. :) > > 1) Installation / Home Page - Pre-flight screen on first boot within a > summary screen. When the product boots up for the first time, rather than > present the GUI with no configurations in it, a first boot screen with items > the system recognizes are completed adequately versus those that need > attention. For example - run the diagnostics and display the deficiencies > with a link to suggested help to fix. A summary section of items that need > attention - no trunks configured, no users configured, can or cannot reach > the Stun server, etc. A summary screen under diagnostics that develops a > list of possible issues based on error codes received, mis-configurations > identified, etc. This ensures the critical issues get resolved before > people try to troubleshoot why a phone isn't working. > > The Home page could be used much more extensively much like a summary > screen. The Gateways could be shown in their own box, Users in their own > box, Phones in their own box, Current Auto attendant being used, music on > hold configuration being used - internal, external, etc., network > parameters, etc. There seems to be a lot of wasted browser space that > could be improved for easier viewing, less clicking, and quicker access to > the area you need to go. > > > 2) Configuration - Wizards are nice for configuring things - phones, trunk > groups, etc. and ensure essential steps are not missed. Increased > documentation of some of the features and what they do with popups or help > button (link to wiki page - so end user community can assist in development > of more extensive documentation). It might be nice to setup a > Configuration section of the Wiki, specifically for creating links to areas > of the GUI to go to for detail documentation. > > > 3) Help - Configurable Help Location. A place to specific the URL for > help functions. This will allow an administrator to configure their own > internal help screens, customized for their local policies, procedures, etc. > Default to Sipfoundry Wiki, but able to change to one's own when required. > This would allow for a company to create their own training video, user > docs, etc. > > > 4) Troubleshooting - Access to underlying data from the Gui. Example - > able to request a tail of the proxy from the gui so it can be viewed > remotely when limited access is provided by IT department. Ability to > execute CLI parameter from the gui and have them displayed in a popup. > Ideally, rather than enter the cli command, it is a link that is provided, > or a script, which drills down to what you are looking for. Start with a > subset of the most asked for items, and then improve over time. One great > example is the ability to clear logs, ability to merge logs, and a link to > download it for viewing in sipviewer. This is one example, others should > be considered, with links for downloading files, etc. simply. > > > 5) Tools - a single screen to be able to watch a call flow would be nice - > empty screen that requests what extension to watch. Shows phone is > registered, shows call off hook, shows digits dialed as they are dialed, > shows the gateway access, shows the call progress through sipxbridge, shows > invite status to carrier, shows progress of call to far end, shows > termination, and many more details in between. This could be a vital tool > for troubleshooting for those that lack much of the skills to troubleshoot > at a packet level. It can help to pinpoint dial plan issues, gateway > issues, phone issues, etc. Then - on call termination, a file is created > that can be downloaded and viewed automatically in sipviewer or pcap > software. Clear button to start the next call progress, or does this > automatically with a list of the files available on the screen. > > > > Thanks again for an excellent product! Hopefully we are giving some ideas > to the developers and their gears are turning, seeing some easy, practical > solutions to put into a quick user experience release package. > > > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Scott Lawrence > Sent: Friday, January 22, 2010 1:24 PM > To: sipXecs users > Subject: [sipx-users] Simplify, Simplify, Simplify > > As we begin to home in on release 4.2, we're starting to formulate plans > for what comes next... > > First, I want to reassure the community - Avaya is very much committed > both to the SCS commercial product (see roadmap announcements made this > week), and to leading, contributing to, and materially supporting the > sipXecs open source project. There most assuredly will be versions > beyond 4.2, and we're committed to making them better with every > release. > > Which brings me to the Subject of this request for community input. One > of the major strategic goals of the release after 4.2 is to make sipXecs > simpler. Simpler to install, simpler to administer, simpler for end > users to use. Nice goal, huh? Motherhood is good, Apple Pie is very > good, and Simplicity is great - I'm glad we all agree :-) > > Now comes the challenging part - what is simplicity? We'd like to hear > what the community thinks... > > Specifically, what are your top 5 suggestions for how to simplify > sipXecs? For this thread, we are _not_ asking for what your favorite > missing power telephony features are (we'll do some of those too) - we > want to know how to make the features we've got easier to understand and > use. What are the things that you have to jump through hoops to do > (especially if you have to do them more than once)? What are the things > you constantly have to explain to users? What are the things you know > how to do but it's just a little irritating ever time you have to do > them? Try to think back to your first experiences - what was hard > before you knew what you were doing (newbies - this is your chance to > jump in and contribute even before you know what you're doing!) ? > > This is not like those dumb Microsoft advertisements where one doofus > after another takes credit for Windows 7 (really - would anyone actually > want to take _credit_ for Windows?) - we really want to know. > > I'm going to suggest one more thing for this thread - that developers > just read and not post. In particular, in this thread: don't explain > that something our users think is hard is actually easy, or tell them > why it's hard, or suggest how we might fix it, or chime in here and now > with your ideas. We'll have our turns to process all this more actively > later and elsewhere - this thread is about listening to our users pain. > Hear, be inspired, and get motivated. > > > > > _______________________________________________ > sipx-users mailing list [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-users > Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users > sipXecs IP PBX -- http://www.sipfoundry.org/ > > _______________________________________________ > sipx-users mailing list [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-users > Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users > sipXecs IP PBX -- http://www.sipfoundry.org/ > _______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users sipXecs IP PBX -- http://www.sipfoundry.org/
