[asterisk-gui] Opinion, what do you want in the gui for users?

[Ming Yong]

Being one of the companies in this space that is dedicated on the 
software side of Asterisk given our involvement in Druid Telephony 
Platform (one of the first commercial GUIs in the market since dec 
2005), I would like to say that user interface design is an extremely 
important topic that has to be linked to the target audience. The 
asterisk target audience is SMEs and telephony VARs. This user base 
requires both a good admin module to administer a system simply (eg. 
add/delete/change extensions, auto-provision phones, setup voicemail, 
IVR, conference rooms, dial plan type editor)
as well as an end user module.

The key reason is simple: SMEs don't typically have the budget nor the 
need to do actually get a third party to do their PBX configurations. 
Hence, the GUI has to do both admin & end user base functions. Most 
important of all and i believe all interfaces including Druid is still 
lacking is how to you expose the true power of asterisk telephony to the 
user & admin without making it "dumb" where the functionality is just 
removed because the user cannot be "trusted" with it.
This is kind of difficult and our attempt at it was the Druid Dialplan 
Wizard that allows any basic asterisk user to be able to create complex 
dialplans using point and click + in-context help.

The end customer SME really does not care whether the backend is 
asterisk or whatever. All he cares is his application functionality, 
usability vs the price point. Which is why in the Druid Telephony 
Platform, we have done A lot of work on the end user modules like follow 
me, voicemail over the web, voicemail to email settings, call 
forwarding, simultaneous rings and of course voicemail password setting :)

Ming
> Firtly I would like to say that I'm very happy with the number of emails
> this list is getting :-) We're going on the right track.
>
> Before Asterisk I had a Siemens HiPath PBX. It had two BRI and 8
> extensions (4+4). The configuration was done with a digital phone (a
> Siemens specific for that PBX series) or using a software, only available
> to the Siemens partners. All configuration was done by professionals and
> the users couldn't change anything.
> Before this experience I worked in big company that had several Nortel
> Meridian PBX with thousands extensions. Here the configuration was done by
> an outsourcer.
> This two paragraphs above make me ask all a simple question: is this GUI
> intended for the end user that has a softphone that sometimes needs to
> change his VM password or is it a GUI for admins, just like that Siemens
> software?
>
>
>   
>> On Fri, Apr 13, 2007 at 04:39:11PM -0500, Pari Nannapaneni wrote:
>>     
>>>> that if you give someone access to configuration (i.e. enable the
>>>> 'config' option) you are giving them blanket access to the PBX's
>>>> configuration files -- including other user's passwords, the passwords
>>>> for your various ITSP accounts, etc.
>>>>         
>>> As most of the users personal settings can be managed from users.conf,
>>> We
>>> can have a modified version of
>>> getconfig for the user (something get_myconfig ) using which the user
>>> can
>>> retrieve/edit only
>>> his section (context) of users.conf.
>>>
>>> This would let the user change most of the things he wants to manage
>>> like
>>> email adress, vm passwords,
>>> sip/iax passwords etc, but we will soon run into the same problem as
>>> steve
>>> mentioned here - which is
>>> this would also give the user ability to change his dialplan etc which
>>> is
>>> probably not what we want.
>>>       
>> This should be done very carefully. Should a user be allowed to change
>> the context into which its extension goes?
>>
>> I'm sure that there are some other ways this allows users to inflict
>> damage on the system
>>
>>     
>>> So using a database looks like the most logical thing here as we can
>>> define
>>> a per entry basis
>>> permissions using a database.
>>>       
>> Why?
>>
>> sqlite does not have any inherent permissions system. Thus if you want
>> such an authorization layer, it would have to be implemented by the
>> application. And hence indirect access to the database by any
>> third-party program will break it.
>>
>> And I don't think you want to depend on an external server to store all
>> the configuration.
>>
>>     
>>> Infact we can even implement multiple levels
>>> of user privileges
>>> if we have database - like [SuperAdmin] --> [admin1, admin2..]-->
>>> [user1,
>>> user2, user3, user4..] etc.
>>> It also have additional benefits like ease of use, ability to do CDR
>>> stuff,
>>> ability to do detail statistics/reports of queues and other resources
>>> like
>>> cpu/network/disk usage etc.
>>>       
>> This requires too much application logic inside the permissions system,
>> IMHO. We'll end up with a huge and monolithic permissions system that
>> can only be manipulated by the GUI.
>>
>> --
>>                Tzafrir Cohen
>> icq#16849755                    jabber:tzafrir at jabber.org
>> +972-50-7952406           mailto:tzafrir.cohen at xorcom.com
>> http://www.xorcom.com  iax:guest at local.xorcom.com/tzafrir
>> _______________________________________________
>> --Bandwidth and Colocation provided by Easynews.com --
>>
>> asterisk-gui mailing list
>> To UNSUBSCRIBE or update options visit:
>>    http://lists.digium.com/mailman/listinfo/asterisk-gui
>>
>>     
>
> _______________________________________________
> --Bandwidth and Colocation provided by Easynews.com --
>
> asterisk-gui mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-gui
>
>   


-- 
Ming Yong
Business Development
Voiceroute LLC
Voice: Dial 650.331.1732 ext 301
Call VOIP => sip:301 at pbx.voiceroute.net
ming at voiceroute.net