So, I'm back to using project management tools again and I've come across OpenProj. So far, it is the closest app to Microsoft Project I've found. I'm enjoying it so far. I'll keep you posted on how it works in the future.
Today we released our team collaboration tool at MondoTeams.com. It is a free online tool that allows you to:
It's all written in CF and AJAX and is free for you to use! There are obvious limitations, like a maximum number of projects (20), folders and files (I'll have to look that up), etc. However, the limitations are generous and should be plenty for most projects.
We are also creating some new and improved features that I'll blog about in the future.
Also, another tool we created is call MondoDesigner.com. This tool allows you to create your own web sites (for those who don't want to get into code), host it on our servers, add a blog, and community sign in, and use your same login and password for all of the Mondo tools.
We have a whole suite of tools and projects that we'll be releasing in the future. I'm way excited about them and I'll keep you posted!
A colleague and good friend of mine approached me about assisting him in developing a somewhat major web-based application. It turns out that the application is a very good idea and I was anxious to lend a hand.
After our first meeting my friend asked me how we could get his supervisor to approve the project. This is a common problem for many subordinates when trying to approach management with a new idea. The following were my recommendations:
For some, its not easy selling new ideas to supervisors or even colleagues. But remember, you're always selling something, whether you realize it or not. Encourage your selling strengths and strengthen your selling weaknesses. Good luck!
One of the most important elements of software (whether desktop or web-based applications) is quality assurance. When we (at DSS) sell a product to a customer, they obviously expect a high degree of quality and usability. Not just for their employees, but also for their citizens. Our products will be used by the public citizens of that state and in a sense our products provide a foundation by which citizens will judge the overall quality and integrity of the state and the services it provides. This is why the quality assurance of our web-based sofware is so important to our customers: they don't want to betray citizen trust (and to avoid looking like idiots).
The sole focus of quality assurance should NOT be from the programmer or developer perspective (as it was early in my programming career). Q&A is so much more than just making sure the programmer thinks the system works correctly. It is ensuring that additions or modifications to software:
I'll briefly explain each of the items:
Because programmers and users are so disparate in their usability logic, a pre-defined "link" must be created for programmers to the user. Some teams create this link by hiring a usability expert or interaction designer. This person is usually solely responsible for creating interfaces for consumers; thus, removing the need for a programmer to include interaction techniques in their development which could save significant time. Interaction designers can also train programmers to instill good interaction design techniques.
"If it was is easy for the engineer to build, it won't be easy for the user. If it is easy for the user, it was difficult for the engineer to build." - unknown
This quote perfectly portrays one of the major gaps between usability and software development. Programmers develop logically (that is, in a procedural way) whereas users scan quickly (which tends to be more emotional). These inherent differences always cause confusion for the user and difficulty for the programmer. Thus, when programmers perform the following non-exhaustive list of checks, users will have a much easier time adapting to the new application:
This is a no-brainer. If the application does not perform as specified in an evolving requirements document, what's the use? The application will not do what is expected and should not be built.
This is not meant efficiency in programming process (query optimization, efficient array processing, etc.) this is meant to explain efficienies in user interfaces and interface processes. For example, if a user needs to create a question to ask in a survey, have them finish the entire process in one screen. Clearly, adding the question text and adding possible responses (for a multi-choice question) should be done on the same screen. The old screen-refresh-at-submission designs are a thing of past (I admit that I have a lot of work to do). Technologies that assist with this are AJAX and Flex.
A major application system is simply a lot of smaller components working together. Keeping those smaller components simple will always provide for a stable system.
Don't plan security into the picture after user testing. Security is an ongoing problem and should be an ongoing concern. Programmers should be routinely and frequently trained in the latest security threats and hacks and those procedures should be implemented DURING DEVELOPMENT; not after it has happened. It is more difficult and more risky to implement security features after development than to implement them during it.
That's on odd one, eh? What I mean by "future-oriented" is that programs and applications (whether web-based or not) should evolve. There should be a continual re-evaluation of the application to asess enhancements, modifications and new features THAT MATTER. There is no need developing anything that really won't matter to users.
In summary, this is simply a short list of a much longer one that may assist with approaching software development properly.
