[Phpgroupware-developers] Ideas and plans

[Alan Langford]

At 2005 04 28 11:44, Dave Hall wrote:
> I for one (and I think there are others) who would be interested in
> hearing your ideas and plans.

The caveat here is that I haven't taken much time to poke around in the 
code. I started... quickly finding the code base somewhat overwhelming, I 
started looking for architecture-level documentation, and then that nasty 
little requirement to put food on the table took me away and left me with a 
little time to generate noise on a mailing list and little else. :(

Let me also say that with a mere four part-time developers, things are 
moving pretty well indeed. I've partially been stumped by the coding 
requirements -- I certainly understand and support the need for a 
consistent style, but I'm just as much a lone gun developer as anyone else; 
I want to have a development environment that will let me look at the code 
the way I want to see it and then reformat it back to team standards on the 
commit. So far I've been unable to tease Eclipse into doing this for me, 
nor have i found a free stand-alone product that will do it.

Now that I've qualified my ignorance, on to features. I wouldn't be 
surprised if some of there are in there and I just missed them. If so, 
enlightenment is greatly appreciated!

<braindump>

Simple stuff:
* When your session times out in eGW and you click on a link, you get the 
login screen, and then it redirects to the page you requested. That's 
really useful.

* Next week / last week buttons in the calendar.

* A host of simple navigation aids in the contact manager, like
1) "save and return to the calendar" beside "save (and show me the record I 
just created)"
2) letters of the alphabet across the top of contact/organization screens 
to let you get to the letter you're looking for in a single click.

Not simple stuff:
* I know this is somewhere between underway and completed... build 
everything around an application services model, where a client makes a 
request to the server through XML-RPC or SOAP and deals with the 
presentation of the response. This will enable GUI clients (I had high 
hopes for IBEX(XWT) once, but it suffers from lack of momentum. Maybe 
XFORMS will do the trick, but I'm leaning to Eclipse's SWT simply because I 
need to get deeper into Eclipse for other reasons. Even a Delphi or Visual 
Basic client should be able to interact with the server to allow rich UI's 
without messing with the core application). By the way I have an unreleased 
XML-RPC library that implements some suggestions that I made to extend the 
standard... this makes it easy to pass PHP class objects back and forth 
across RPC calls without the complexity of SOAP. I'd be happy to contribute 
this if it's wanted; I plan to make it generally available when time 
permits (alas, I've been saying that for a year now).

* Document the services architecture described above, allowing people 
creating new functionality to build consistent services (this can be as 
simple as rules like "always use 'addNew' for creating a new entity", or it 
can be quite detailed).

* Disconnect the database from the application with a similar services 
model. This makes it easier to have a distributed database. It also makes 
it easier to make the back end an array of supercomputers running DB2 
clusters. ;)

* Convert every auto-increment unique key into a GUID (admittedly this is a 
fat solution but I think it's worth it). Use the GUID's to simplify 
distributed database servers by eliminating record ID conflicts.

* Improve the contact manager. This is an area where I have done lots of 
work -- much of my time is spent in call centers. From what I can tell, the 
architecture of the current contact manager has many things in common with 
"my" ideal schema. This is both very cool and a big problem. It's very cool 
because you can accurately represent the way the world is. It's a big 
problem because it's difficult to hide the complexity from a user, and 
performance can suck. At a minimum, we need a "add contact wizard" that 
does things like let the user type in part of a organization name, where 
the system returns guesses at existing companies or allows the creation of 
a new organization. This is where a non-Web GUI really helps. Right now the 
add contact process is sufficiently complex that I usually just stuff the 
organization name in the department field, which is wrong, wrong, wrong.

* Add networking links to the contact database. Sort of like a mini version 
of likedin.com, I want to be able to tie people and organizations together 
into networks with relationships like "subsidiary of", "partner of", 
"worked for", "married to", "strongly dislikes", and so on. Then I want to 
be able to search the network with questions like "Is there a link between 
me and company X?"

* Significantly improve data validation and formatting in the contact 
manager. I have code (alas, not written in PHP) that:
1) performs table-driven validation of phone numbers (so 1-416-555-1212 
gets rejected) with full international support (although the tables are 
only sparsely populated for non North-American calling plans);

2) Parses addresses with an AI like recursive descent scoring algorithm 
(alas, very tuned to North America just because I don't know much else). 
This will take a string like "351-25A E. 54th St. New York NY 10210" and 
return (unit=351, unit_type=Apt, street_number=25, street_number_suffix=A, 
street_type=Street, street_name=54th, street_dir=East, city=New York, 
state_prov=NY, country=USA, postal=10210). Addresses are *way* to 
complicated, and I haven't even touched on post office boxes and rural 
routes! It would be very powerful indeed if phpGW could do this for 
international addresses.

In an ideal world, the user types in the information on a business card, 
and the application fills in all the fields with an accuracy over 95%.

* Add geocoding to contacts. I want to be able to say I'm going to visit a 
contact and have the contact manager tell me who else I know within a given 
grid around that point, so if I have to drive across the city or fly across 
the country, I can make the most of the trip.

* Provide an option for a really simple contact schema... the standard one 
record per contact stuff. If you're a developer or a salesperson, the 
complex schema provides amazing power and flexibility, but in a call center 
environment, the key factor is number of milliseconds needed to pop a 
contact screen. The application services should be the same for both 
back-end models, except that if a complex operation is attempted on a 
simple schema the result is "not implemented in the simple schema".

* Build in a mess of CRM features, including work lists and workflow. 
Workflow goes from simple things like "automatically schedule a follow-up 
call with this contact six months after a call is logged" to more complex 
events like "if this record is closed with a 'sold' disposition, add the 
record to the work list for the verification department". CRM covers stuff 
like projecting sales, reporting, etc (see salesforce.com, sugarcrm.com).

* Integrate with asterisk, the open source telephony platform.

Major re-engineering stuff:
* Revise templates to use XSLT. Make all intermediate layers hand XML to 
each other. Detect browser types and pass the XML/XSL to them to get them 
to do the heavy lifting when possible.

Philosophical stuff:
* Target audience. This "support older browsers" stuff is fine if it 
doesn't limit the presentation, we should scale to handle the browser's 
capabilities. eGW handles the "too many apps on the toolbar" problem with a 
<DIV>. You click on the "more" icon, and this very nice list of additional 
apps slides into view. It's cool, it works, it's better than what we do. 
The recent discussion of functionality versus sizzle is quite appropriate. 
Sizzle sells, it's a fact, Micro$haft is proof of that. QED, etc. But 
sizzle *and* functionality and stability beats just sizzle or just 
functional, every time. We ignore this at our peril. Disclaimer: in the 
past few years it seems I've alternated between two titles, "CTO" and "VP 
Marketing" (in small businesses, so the titles are loftier than the jobs 
were), so those of you who think marketers are evil can just delete this 
message completely and continue on. ;) Our marketing sucks, by the way, but 
right now it's less important than getting core functionality up to scratch.

* I find that there's a real blur between "groupware" and "content 
management", when there seems to be very distinct needs for the two classes 
of application. Sure, most groupware applications have a content component, 
and that component needs management. Sure most content management 
applications tend to need to support a user base, but rolling the two into 
one seems fundamentally flawed.

I currently have my head very deeply into the content management space, and 
all I can say is that in general, all the OSS solutions out there need 
serious work. I'm using a pretty nice package called eZ publish 
(http://ez.no for expediency -- I have customer with a time line), yet at 
the same time I have a few reams of notes on how to do it "right". Without 
writing a book here, let's just say that the presentation layer should be 
XSLT and the target for a CMS should be more generalized than "a Web browser".

What this has to do with phpGW is that it should be possible to plug in 
groupware capabilities into other applications, which means decoupling 
things like user logins from the rest of the application, so a Web site 
designer can have a framework that manages users, then elect to plug in 
phpGW for contact management while using some other package for content 
management. If everything is done with an application services model, this 
shouldn't need a brain surgeon to implement, but there's a hell of a lot of 
work to be done to get there.

<braindump/>

So there it is so far. Everything from a tweak to a massive rewrite. *sigh*