Jeff <[EMAIL PROTECTED]> writes: > I was really hoping to avoid an entirely web-based app, for a few > reasons, not the least of which is that I've been working almost > entirely on web apps for the past few years, and I am getting mighty > sick of it.
If you've done any gui programming, you'll know that it's even more tedious and time-consuming than web programming. At least the way I do web stuff, I'm a back-end coder so I slap together a usable interface with crude html (the only kind I know), then let a real web designer handle making it look nice (that person doesn't have to be a programmer). It's relatively easier to get someone like that involved in a project than someone who can do good visual stuff AND write code, as is (to some extent) needed for a client side GUI. > But I'd really like to try something different. A year-long mission critical project is not the time or place to try something different. Better start with something easier. > Some reasons for them would be (in no particular order): 1) More > responsive and user-friendly interfaces, 2) Much better ability to > sort, export, import, and print data (very important), 3) Easier to > "lock down" who's using the program by only installing it on certain machines. 1) is true in principle and but a heck of a lot of apps don't really use the capability. There's tons of crappy gui apps out there that could be done just as well with no client installation. 2) I don't understand this part. Sort = server side. Export/import/printing: upload and download files? Depending on your requirements a little bit of browser scripting may be enough to handle this. 3) I don't agree with this at all, and if you were trying to pitch your project to me I'd be asking you a lot of questions about security, in particular whether you're up to integrating SSL into both your server and client, as well as they're already integrated into existing browsers and http servers, which were written by experts and have had tons of review and testing, yet problems still occasionally turn up with them. (Hmm, maybe you could use something like stunnel, yet another client install.) Since you're handling personal and financial info maybe you should be using multi-factor authentication (hardware tokens with client certificates) and browsers already handle the client side of that (Windows CAPI in Explorer or PKCS#11 plugin for Firefox). > usability of a desktop app is rather frightening. I've done plenty of > stuff with AJAX, and it certainly has its purpose, but it gets > incredibly bloated and fragile *very* quickly. Yes I agree with this. There are multiple judgement calls as to 1) when the maintenance tradeoff starts tilting towards a thick client vs AJAX when you need certain interface features that can be done either way; and 2) whether you REALLY need those features. Again, if you were trying to pitch this project to me, I'd want to see some sample screen designs with a persuasive argument that their functions couldn't be done as effectively in html, if necessary using a small java applet or embedded browser plug-in to handle stuff like file i/o or whatever. > My manager even wants use cases (if you've never had to deal with > use cases, consider yourself a lucky, lucky person) which I am going > to attempt to argue as that is even going *too* far. You definitely need use cases. You should also put together some sample screens to figure out the user interactions. You won't be surprised to hear that I usually do those in html. > So, long story short (too late), no Extreme Programming for me. I'm not a real adherent of Extreme Programming (abbreviated XP, not to be confused with Windows XP) like some folks on this newsgroup are, but some of its ideas are worth studying. In particular, doing bite-sized incremental development with very frequent interaction with the customer, letting them try out new code as the implementation progresses, can save you from surprises. -- http://mail.python.org/mailman/listinfo/python-list
