vicidial.org

Hi Matt,

Here's the design im working on. Some of the features are working, but i am experiencing some bug so need to fix this up first.

Here's the image of the LIVECALL test leads.



What do you think? By the way the Hotkeys should be on the lower right of the tab area.

Note:

I changed CC Name(Province), CC Number(Email), CC Expiration Date and CC Security Code(Security) due to client request but can be easily revert to the original name.

It does look cleaner than what it looks like now.

For the future we need to think about how we are going to allow for customized fields per campaign. It is a feature that will be coming, and we need to figure out the best and most flexible way to allow for that in the agent screen. Any ideas?

I was planning to have a default and common FIELDS, and create one page (z-index) on the lower portion of the fields and labelling it as Campaign Fields.

But the problem is the uploading of fields. Because only the common fields can be uploaded and other customize per campaign fields are'nt.

Yes, that will be a difficult issue, especially if you still want to allow swapping of lists across campaigns. Moving away from a single universal table opens up all kinds of problems.

Yes unless we create a universal "no-label" fields (1 or more) and can create a customized label per campaign on that fields.. What do you think?

Example

Openfield1
Openfield2
Openfield3

and then create a new TABLE that will point on what are the names (per campaign) of each openfield

That does sound good, but how many fields are enough? And what column types should they be?

I set up a campaign with a web form page that had over 100 fields, do we really want that many extra fields in a custom data table?

Let me check about it. Thats the problem if we created numbers of open fields rather than the system generates fields it self per campaign.

Hi

if we specifu additional open field, what name its going to be linked in database.

should be a good idea to chance the open field to known field later.
depends on requirement.
ram

ramindia wrote:if we specifu additional open field, what name its going to be linked in database.

should be a good idea to chance the open field to known field later.
depends on requirement.
ram

We would create a new table for that.

I thought we can have a default web form which will be built and customized by the Dialer Manager using a Form Building tool. That way no need to go into the existing CRM layout, but instead it will be a add on feature.

Do you think its a serviceable idea?

Regards

devafree

That is a good idea. I've had a couple of people mention phpClick to me:
http://phpclick.sourceforge.net/

Do you think that would be a good way of implementing a form builder, or should it be something more customized?

how about using smarty?

Smarty could work, but I was thinking something a little less technical for the room-manager crowd, like php click which is for non-programmers. smarty is really just PHP programming shorthand.

I solved this problem... but i used an not very orthodox way.

I wrote a funtion that read fields from a mysql's table and auto-builds form's fields using values stored in the 'comment' field.

I'll try to explain better: when i need custom fields, i create a special mysql table for those fileds, putting for every field, some settings in the Comment value, separating them by a pipe (|), for example: size, label, kind of field and many others using a my own format. Of course there is a php page (front end) that create the custom table in that way for each campaign, so every not-programmers could do it.

When the script needs those fields (for example the vicidial.php) it calls that funtion that builds the form exactly like we expect. After the phone call, vicidial.php just could stores result values passing them to that function, that will stores the values in the custom campaign's table joining it with vicidial_list leads using the lead_id.

I said, it isn't a very straight way but it works very well. Say me if it could be useful for yours purposes.

That could work, but across systems with 7million leads, adding a new TEXT field to vicidial_list (I would not want to take away the comments field for this) would not be very flexible or efficient.

I paid my bad english... I'm sorry.

I didn't mean to use the vicidial_list.comment, i mean a different thing.

MySql give you the faculty to add a comment for each field, so when i create one new 'custom table' i put in the comment flag present in each new field all the informations that will help my script to auto generate (adding) the right <input> field inside the document.vicidial_form.'custom_filed'.

In other words, i used an <include 'myscript.php'> inside the <table> in vicidial.php with contains all document.vicidial_form.* and when vidicial.php loads its page, myscript.php build the custom fileds, using the informations present in the 'Comment' value inside the MySql table (size, class, label,field names etc). So when I create a new Campaign, I just choose the new custom fields and another my own script automatically create a MySql Table putting those information in his comment flag.

The harder side was to edit manager_send.php to send and receive the newest document.vicidial_form.'custom_filed'.

I hope that i was less obscure now, but i'm not so sure

very interesting, I had never thought of doing anyting like that. Can you post your code on the issue tracker?

of course.

Hello

IMHO , the phpClick seems to be a beginning stage and may not be suited for full scale production purposes as of now.

Also, a Vicidial form builder will be great .

I was thinking that a WYSIWYG html editor, Nvu, can do the job of Form building quite easily as a front end tool. If we create a html page by default that gets the default vicidial list data , that web form can be opened by the call room managers in Nvu and there they can build the form. The default value for all fields should be given as some $my_web_form_var prefixed one inside the php tags. The form builder script will read the saved file and display the new field names alogwith other options to be chosen. Such options can be field validation on the server side, access level (eg. different levels for the agent, the manager, the admin, and perhaps even the client).

Once that is saved then the form builder script will read that file and create the table inside the asterisk database itself. Then, the validation and access etc can be written into the web form from a library.

Then the values for submit buttons etc like add , modify delete , email, or whatever can be got by the web form builder script thru user input from the room manager and then incorporated.

As I am just getting started on programming , please excuse any infirmities in the idea. I am thinking aloud here.

Regards

Devafree

NVU sounds great, but I think a simple form builder in the web admin would be a better starting place before we would involve a separate application that would need to be loaded on a machine to use.

Hi

Looking at the comments on this thread, I would suggest a look at RoR (Ruby on Rails). This could address much of the database abstraction that is mentioned.

I know there are a few Pear modules that could also work (indeed Smarty would be a good idea - as previously suggested in the thread) but for 'out of the box' functionality, as well as tightly integrated AJAX functionality, I believe that RoR would provide an excellent platform - and that's coming from a PHP advocate!

I am yet to get my hands dirty with VICIDIAL (I will be looking at it over the next few weeks) but I think there is huge potential with RoR.

In addition, I have been in dialogue with Matt regarding the potential of incorporating a 'dynamic script' tool (known in the telemarketing industry as branching and skip logic - I believe) that would allow agents to have a more intuitive call with their subjects. Again, this is something I will hopefully be looking at in the very near future.

It is my intention to replace the existing proprietary technology in a 400+ seat call centre (mixed inbound / outbound) with a mix of Asterisk, VICIDIAL, LDAP, LTSP (Linux thin clients) and MySQL/PostgreSQL open source technologies. An ambitious project...

Any comments would be welcome!

Regards

Joffliver

I really don't want to add another programming language to the mix of the project. I've had people wanting to add Java, Java servelets/JSP Mono/.net and many other languages to the mix and I really just want to keep things as PHP/Perl with Javascript/HTML for the interfaces to keep the project from becoming unmanagable.

I am also beginning to think that no out-of-the-box solution is going to work for this. For building of forms I think that we really need a custom built solution that will work well within the javascript of the client interface as well as be easy for a room manager to be able to use. There should be limitations on it so that it is not too difficult to use while still keeping data and formatting integrity in mind.

The tree-structure feature will be a good thing to keep in mind as we are figuring out how to build this because that will need to be very flexible and allow for a dynamic custom campaign that can change along with a method for storing the data that will be flexible with it.

I hope to have some time after I finally finish 2.0.3 to get into this stuff at a code level.

Already finished the new design for Vicidial Agent's Screen. will submit the full code as soon as i finished further testing this week. This design is for 1024x768 and above resolution only.

That sounds great!

Do you also have any ideas for the new VICIDIAL logo?:
http://www.eflo.net/VICIDIALforum/viewtopic.php?t=3457

Are the screens for 1024x768 available anywhere currently? I would love to toss them onto our test server.

We are also in the works with integration for Asterisk GUI. I am going to see if i can rebuild each conference room and component required for astguiclient in Asterisk GUI. Currently the inherited items in extensions.conf showup in users (conferences, users, etc. etc.). So it is pretty cluttered currently, but I hope to clean that up.

We looked into the trixbox integration, and hated the attempt. Talked abit about asterisk gui, and after testing it just parses the configs and shows you the content in them, so no fancy dial plans you dont make. Although parsing extensions.conf currently is messy as hell, so a rebuild is required, at which point I will drop the basic configs back for others. However I would love to have the new 1024x768 look to go with the GUI for asterisk configuration.

Thanks,
Trevor

Are you talking about the Digium Asterisk GUI? The one included with AsteriskNOW?

Yeah. From all our testing it just reads the config files. I can manually edit the conf's and then it just shows up when i refresh the GUI from digium. However the current extensions.conf is parsed into each 'frame' (like users, conferences, etc. etc.). So i am tracking down how they structure the conf so it breaks down nice and clean, and I will recreate each conference room and component through its interface.

So far the Digium GUI looks to just be a frontend to the confs with the ability to use their commands directly if you need to build something. So no Macrodial and such to loop repeatedly. Looks very nice and clean, just not with the vicidial extensions.conf, yet. But that should be done maybe this week.

That would be great, I would love to integrate VICIDIAL with the Digium interface.

If you get a working set of instructions or a working set of conf files, please post them to the issue tracker.

Yep that seems to be a nice idea.

Are the 1024x768 uploaded to the tracker already? Were replacing a vicidial call center and would love to use the new ones instead of adjusting the pixel placements on manual dial, callbacks, and volume controls.

Is it just me that has these placed funny in 2.02?

Trevor

Some of those have been moved with 2.0.3, have you looked at that yet?

Where would you like to place Callbacks and manual dial?

Mainly on the systems were using we find that manual dial and agent callbacks are on top of the comments box or at least partially. So i drop them about 15-65 pixels or so to stop the overlap. I tried changing screen resolutions around, but didnt seem to affect it. Wasnt sure if it was something to do with the version of firefox either, so i just changed the code slightly for placement about 1/4 of an inch lower.

We didnt turn those features on until manual dial with alternate lead dialing, it didnt seem to push the entire page down, but maybe i just didnt realize it did, and have not tried with auto dialing.

Trevor

I have done some work on moving some of those fields around, take a look at 2.0.3 when I release it later this week and see if it looks better to you.

any news about this design?

Just finish the new design for 2.03 version of Vicidial. You can download the file here:

http://www.eflo.net/VICIDIALmantis/view.php?id=104

Comments are highly appreciated. Already tested on working environment and so far its doing okay.[/img]

Hi

thats great work
any installation proceedure

or is this included in SVN?

ram

just put it on your web folder... let me know if it works perfectly

Wait... there's a bug in the recording side. Let me change it first and upload a new file in a while

Hi

look at pause and resume also

ram

So far, I did the testing and it works. Once the Manual Dial method is selected logout and login and it will be changed to Dial Next number. Can you try it again?