Help me design the next killer app

[yoshida]

Hi. A little background on me first.I'm an architectural drafter (CAD), and the next big thing is not CAD but BIM (Building Information Modelling). This means both my webdesign/database and my CAD skills come in crucially handy. Right now I 'master' XHTML/CSS, am experienced with PHP/MySQL, and I built my own php-based content management system.The last few days I've been working with Javascript. I consider browser sided scripting as messy and not reliable, so I prefer to do serversided scripting. However, 'realtime' interactivity and dataflow holds the future (not only for webdesign but also for BIM). So I decided I'd like to learn some AJAX and XML too. (where do I start?)For a pilot project, I'd really like to create a new webbased application. The keywords are secure, multi-department, reliability, realtime, real figures. I'm prepared to invest a lot of time and learn many things, as long as they all lead to solid results. I'm both the contractor, builder, designer, tester and user of this program, and would like to expand it as time goes by. (OOP anyone?)Generally, what would be the best way to design a web-based interface that has the look and feel of a real program, using the languages described above (preferrably HTML/CSS, PHP/MySQL and AJAX where applicable)? Would you load JavaScript from a database, so the administrator can edit them anywhere, anytime? Would you put all PHP scripts in one file, have all departments use a seperate file, or make as much scripts as possible? What is Object Oriented Programming, and why does it look handy for this 'job'? Please note that I'd like to consider a big number of opinions before doing any research and scripting.Feel free to use any contribution in this discussion for your own good. I'd like to thank anyone in advance for his or her co-operation.Bram Weinreder, 'junior' webdesigner

[zppblood]

Object Oriented Programminghttp://webopedia.com/TERM/o/object_oriente...amming_OOP.htmlI don't think you should ever put all scripts in one file, make different files for scripts and include them.

[yoshida]

I've done some thinking about that. Not only do I maintain websites with roughly the same functionality (try updating the guestbook for three websites for instance), in my scenario the same action might be used in different contexts where only a few variables should be parsed to define that context. I guess this is also where OOP comes in handy.The major difference between a regular application and a web application, is that a web application doesn't have doubleclick functionality. So if you'd want to have options for a certain item by clicking it once without refreshing the screen, you're bound to use iframes or AJAX (object context window). From there I think it should be possible to open a popup to change some options, or just make a two- or three-level-context based on AJAX. I don't know.Lots of learning to be done ^^

[Skemcin]

...design a web-based interface that has the look and feel of a real program...

Why can't a web based application "be" a real program.Anyway, without project specifics one can only generalize a response. As far as OOP, the main advantage to this approach is that it will separate your design and functionality from your data. This, in the most simplest terms, makes it easy to maintain code in the long run and it makes it easier to expand functionality. Of course, the biggest advantage of OOP is that you can repurpose objects easily which makes information more readily accessible when you need it.As far as figuring out what you database and the how and why's behind that, it will all come down to your planning. Your plan will dictate what functionality you want to be available. The more you database the more complicated things get, for both the administrator and the author. The user might only see slight performance hits with a page that requires more database calls to generate the results. If you do decide to put javascript and/or css code in the database, then you are moving toward more of a meta application - where EVERYTHING is databased. I'm not getting into that right now, my only point is PLAN.A general rule of thumb is this, however much time you allocate for development should also be allocated for planning.

[reportingsjr]

Yes, but how often does that happen Skemcin? Unfortunately, not enough. That would be hard to design the next "killer" application. You need to know what the people want, and what you want. Apparently neither are known as it seems. You just need to learn from the people, not us..

[Skemcin]

Yes, but how often does that happen Skemcin? Unfortunately, not enough. . .

With me? All the time. And that is why I have applications that I've built for clients over 5 years ago that are still running strong and have never, yes never, had a bug or major enhancement/overhaul. And that is the whole point of mentioning it. You, on the other hand, might be a different story all together. How many commercial or government web based applications have you built that have stood the test of time - 5 or more years without a single bug report?For others, you might be right, which is exactly why I mention it. But just because other people do not give planning that much respect doesn't mean that the rest should follow suit. To deprive anyone the understanding of a what is most advisable is just setting them up for failure or at the very least not helping them to succeed. I, for one, do not wish to do that to people so I choose to help others understand what is most advisable.So, what should yoshida get from your reply - "yeah, planning is good and everything, and it is an important part of any project, but no one spends enough time on it anyway so don't waste too much time on it."?

[aspnetguy]

Yes, but how often does that happen Skemcin? Unfortunately, not enough. That would be hard to design the next "killer" application. You need to know what the people want, and what you want. Apparently neither are known as it seems. You just need to learn from the people, not us..

Well yes you have to know what people want, it's called research. It is how you keep from going bankrupt in the software industry (and pretty much any other industry).If you do not plan out your application then you will end up with a horrible, unmaintainable, mess of code, that is if you ever get it finished.You should not write a single line of code or even start the interface until you have a solid plan. Otherwaise oyu will be changing things and re-enginerrinrg it everytime you run up against a problem you hadn't thought of or planned for.

[justsomeguy]

Also, just to point out, most "killer apps" don't arise out of a discussion in a public forum, for the simple reason that if people were thinking about it, it would already be developed by the guy who thought about it first. No, the proper place to design a killer app is on a bar napkin. That is specifically what bar napkins are for, and also for getting phone numbers.

[astralaaron]

Also, just to point out, most "killer apps" don't arise out of a discussion in a public forum, for the simple reason that if people were thinking about it, it would already be developed by the guy who thought about it first. No, the proper place to design a killer app is on a bar napkin. That is specifically what bar napkins are for, and also for getting phone numbers.

Hahah

[yoshida]

OK good point, planning is crucial. I mostly draw what to put where on my page first, and how many databases I want and what they should contain. Then I decide what scripts I need to make the entire thing do what I want.Let me give something away to talk about. What I'd like to do is link an IT configuration management database, a user database, and an incident database. True, it has done before, even as a web app, but why not link it with the entire company's financial database and everyone's calendar for example. I'd like to be able to add pieces to the puzzle that is the company's administration. Altho I guess financial administration will be the trickiest module. BUT once I've done that right, it will be easy to track all assets because they are in the database, and there's a module to link assets to network users.Please note this is all conceptual, and I realize PHP will simply be insufficient for a userfriendly look and feel. Rather I'd let AJAX do the initial communications with php on the background if possible.

[Jonas]

Also, just to point out, most "killer apps" don't arise out of a discussion in a public forum, for the simple reason that if people were thinking about it, it would already be developed by the guy who thought about it first. No, the proper place to design a killer app is on a bar napkin. That is specifically what bar napkins are for, and also for getting phone numbers.

Only in reverse order.

[jesh]

Would you load JavaScript from a database, so the administrator can edit them anywhere, anytime?

I would say no to this. Once built, client-side scripting generally isn't going to need to change. Also, if you put all of your javascript into an external file and reference it from the web page, clients will cache that file and will only have to download it once (or when the content changes). For high-traffic sites, using external javascript files will cut down on both the server overhead of having to make a database connection to fetch the appropriate data and also the overall bandwidth that is being processed by the server(s).

[Chocolate570]

Only in reverse order.

Not for most of the people on this forum, I bet. :)Yeah, planning is crucial to a big application...but whenever I'm coding for coding's sake, I try to not plan anything and just go for it. It helps me because I'm not tied down by my own specifications. I just write what I want and whatever features come up are fine with me.

[Skemcin]

Not for most of the people on this forum, I bet. :)Yeah, planning is crucial to a big application...but whenever I'm coding for coding's sake, I try to not plan anything and just go for it. It helps me because I'm not tied down by my own specifications. I just write what I want and whatever features come up are fine with me.

I understand why this approach "seems" to work for people but I would really challenge you to give it a little more thought. Granted, you could start off saying, I'm going to code a ColdFusion Blog application. After maybe 5 or 10 minutes of thought, you and many of us are probably competent enough to code by the seat of out pants. The end result, whenever you decide to stop since there is no defined end point without a spec, could be a very functional and stable application that will meet and maybe exceed your original expectation - I've gone down that road myself. But when it comes time to maintain or expand the application, you are likely to spend more time going back over your old code to squeeze in hooks to the new code/functionality. All in all, it looks like a modern three car garage attached to a mobile home supported by jack stands - it works, but its not what should really be done.So all in all, I doubt many folks (except maybe reportingsjr) will argue the importance of planning. Eventually, it simply comes down to your personal level of discipline. I'd encourage EVERYONE to give planning a chance. Its a good habit to get into and the rewards, although not instant, are well worth the investment.Be patient, plan!(it'll put hair on your chest)BTW, can anyone name any other industry that bypasses planning before executing - current US gov't notwithstanding.

[Chocolate570]

Oh man. They told me that the hair would stop coming. >_> Gosh.:)I do totally agree with you. It is much harder to maintain a code written out-of-the-air than one where you know how it works extensively because of your collection of bar napkins.

[Skemcin]

Oh man. They told me that the hair would stop coming. >_> Gosh.:)I do totally agree with you. It is much harder to maintain a code written out-of-the-air than one where you know how it works extensively because of your collection of bar napkins.

lol, whew, I thought for a minute that your file cabinet was filled with napkins. That would be dangerous if you ever ate pizza near your desk . . . I can see it now . . . "err, man pizza sauce all over the place. I need a napkin. Ahhhh, there we go! Whew, that was close. That almost got all over that idea I had. Nooooooo, I can't believe it! $^&*(#@ now I got pizza sauce all over my idea. Looks like its back to the drawing board - where's my beer!

[Chocolate570]

lol, whew, I thought for a minute that your file cabinet was filled with napkins. That would be dangerous if you ever ate pizza near your desk . . . I can see it now . . . "err, man pizza sauce all over the place. I need a napkin. Ahhhh, there we go! Whew, that was close. That almost got all over that idea I had. Nooooooo, I can't believe it! $^&*(#@ now I got pizza sauce all over my idea. Looks like its back to the drawing board - where's my beer!

Hah! I usually do eat pizza while using the computer too. I know see that's a bad idea...:)Then there's always the chance that you'll spill beer on your rejuvenated idea. Where can we brainstorm?

[Skemcin]

Hah! I usually do eat pizza while using the computer too. I know see that's a bad idea...:)Then there's always the chance that you'll spill beer on your rejuvenated idea. Where can we brainstorm?

Where everyone else does - on the toilet. Just don't wipe your arse with the toilet paper you jotted your idea down on.

[justsomeguy]

You can get a grease pen board for the shower. There's nothing like having everyone crowd in your shower to take a look at your newest idea.

So all in all, I doubt many folks (except maybe reportingsjr) will argue the importance of planning. Eventually, it simply comes down to your personal level of discipline. I'd encourage EVERYONE to give planning a chance. Its a good habit to get into and the rewards, although not instant, are well worth the investment.

"Planning" is a pretty generic term, it almost undermines the importance. One of the required classes for a BS degree in computer science at ASU was an intro software engineering class. Software engineering is the term for essentially designing software. If you have a development team consisting of one or two software engineers and several programmers or coders, the software engineers might never write a single line of code themselves, but they will probably be the most talented and highly-paid members on the team. Software engineering is no joke, there are huge benefits towards having a good design document and implementation plan laid out before any code is written. It helps for small projects, and large projects will not be successful without it. In other words, it is required for large projects. If a large project does not have a solid design document and implementation and testing plan, I can almost guarantee that the project will fail due to cost overruns, deadlines pushed back, features that never made it in, requirements creep, etc.When I sit down to make an application, and I'm doing it for fun or because it's something I need and I know how I want it to work in my head, I don't worry about a design doc, it would almost be superfluous at that point. But when I am designing an application for a client, of any size, I always give them a design document that they autograph for me. It serves several purposes. First, when they tell me what they want, and I think about it, and put down what I understand on paper, it is very clear whether we are both thinking about the same thing. If there are problems, they will be addressed in the design doc before any programming starts. That way, when I give them the first version, we are both on the same page and we both know what to expect, there aren't any surprises. Secondly, it gives me a list of features that will eventually be in the application that I may need to plan for from the beginning, such as during database design. Thirdly, and possibly most importantly, I have a document describing all of the features of the application with the client's signature saying they agree to it. If the client comes back to me during development and starts talking about new features that they didn't think about during the design, I can pull out the design doc, show that the new features are out of the scope of the design doc, and that allows me to charge extra for doing the new features. I bid a project early on that turned out to be a nightmare project, our design doc essentially said "we will make a site that will allow you to conduct your business online", it was extremely vague and did not limit the application to any set of features. They bombarded us with new feature requests to the point where I literally spent over half of the total development time (several years) on a single page, literally. There were so many change requests and people telling us different things that development essentially halted on a single page in the application. To make a long story short, we started charging them for new changes when we could, and eventually we just had to kill the project. At about 50% complete, we gave them everything we had and told them to find someone else if they want changes. We probably lost several tens of thousands of dollars on that job, and the single reason is because of a lack of a solid design doc.Let that be a lesson to you.. now get off my lawn.

[yoshida]

So I sparked a disussion about napkins. Glory me. :)This is what I came up with after some research (and a number of tutorials). I'll use javascript in combination with xml/xsl (as a way to cache and format data), javascript will transfer info from the xml file to the interface and manage click behavior, and will transfer/update information from the form to the xml file.JS will also tell the serversided script to sync the database with the xml file. I'll try to make everything oop.I have only read about dtd's this morning, and I have yet to create a working js, but when I do I'll find a way to make it work. I'm a persistent soab.So XML will be the cache between the interface and the server, while JavaScript will have to deliver the user experience.Does anyone have experience with xml-based communications between js and php, or recommendations for a more efficient method? Please help me think into the future, and not in the past.I'll have a design doc up 'pretty soon'.