Archive for July, 2008

As a follow up to our post a few days ago titled “Task Tracker Redux“, here’s a list of an additional 36 web-based task trackers that we didn’t mention.

Here’s a recent article from CNN Money on the value of web-based software for managing a business.

Life at Basecamp - six months in - Jul. 8, 2008.

As great as Basecamp is though (we use it), it’s not a magic bullet.

But as you grow, listen up: Expect to either make a major investment in developing your own financial and tracking software that works with Basecamp to make it do what you need (37Signals provides an open applications development toolset, so this is certainly possible), or budget for integrating another, more traditional, and more complex project-management system with Basecamp - or plan on abandoning the software entirely.

This is exactly what make custom software development so valuable. It’s a smart move to get started with a best-of-breed tool that you can use right out of the box. But, as you depend on it more and more you’ll realize that it’s taking over your business. You’ll be forced to shape more and more of your business practices around the way the software works. Ultimately, that’s not a good thing.

When best-of-breed either isn’t good enough or just starts to get in your way, that’s when you need to call a custom software developer and system integrator like Evans Codeworks. They can integrate the existing package into a system which keeps the best and none or some of the rest. The resulting solution leverages all of the good from your existing investment and gives you the freedom to improve on the parts that don’t work so well for you.

I’ve received a number of emails from people using the table of contents plugin. They’ve had some interesting questions and suggested some good use cases.

I’ve updated the plugin documentation to include answers to their questions and responses to their feedback.

To everyone else, please try using the plugin. And send us a note to let us know your experience. We love to hear from you.

This is reply to Ali Loghmanis post “Why is Web UI Development Slow?” on DZone.

Nice post Ali.

I have to agree with you. HTML and Ajax is the best solution out there right now. Granted, the world would be a better place if we didn’t have HTML and could code everything straight in our language of choice. The fact is however that we’ll be stuck with HTML for years to come. So we’d better figure out a way to be productive with HTML in the mix.

Re: the cross-browser issues. I used to struggle with those issues as well. Did for years. The javascript frameworks such as Dojo, MooTools, JQuery, Prototype and ExtJS that have come out in the last few years have made the cross-browser issue all but non-existant for me.

The problem that the HTML layer introduces is a break from the server-side runtime environment. It’s a problem no matter what language or framework you use. It’s a problem with the underlying web ecosystem.

The best way to work around it, to bring the backend and front-end closer together is to embrace it. Stop trying to put a square peg in a round hole. Do one of two things:

1) Build rich interfaces using something like Flex or Flash (as someone mentioned). However, this just swaps around the pros and cons. RIAs (Rich Internet Applications) have many advantages, slick looking UIs not being the least among them. They don’t solve the basic problem howeer. They make UI construction easier. But you’e still got to integrate with all the backend systems such as XML-RPC and SOAP-based web-services. Plus it’s a whole new syntax and development infrastructure to get accustomed to.

2) Expose data access on the server-side via JSON or XML formatted data feeds via services and construct UIs with using JavaScript for some things. I’ve seen component-oriented JavaScript frameworks, ExtJS comes to mind, tend to suck developers in, encouraging them to build entire UIs with Javascript components. This is a huge learning curve and can result in a real mess. I’e seen it happen. So I recommend using Javascript just to handle whatever needs to be dynamic after the screen has rendered. This leaves the majority of screen functionality to be coded on the server side, while providing the responsiveness and esthetic appeal of a responsive, dynamic, javascript-enabled interface.

My big thing is that I don’t need more tools in order to build better apps in less time. I already have all the tools I need. I don’t need more syntaxes, toolkits, development environments, etc. I have a great deal of success building apps with just the fundamentals of HTML, JavaScript and a server-side scripting language.

I’ve found it’s much more effective for me to stop looking outward to the developer community for a framework that will solve all my problems. I’ve been disappointed by hyped-up solutions too many times. I’m finding that by being more diligent and more clever with the fundamental components of the environment (web, desktop, mobile) and server-side language I’m developing with, I’m able to develop more functionality in much less time. And the resulting application is simpler and easier to understand and maintain (because there are fewer frameworks to understand).

I think it’s great that your readers are suggesting alternative frameworks. But, just like wearing Air Jordans won’t make you play basketball like Michael Jordan, using a better framework won’t make you a better developer. I don’t mean this as a criticism at all. As Donald Knuth said, “Software is Hard”.

We should experiment with different architectures and solutions throughout our careers. We must continue to learn and grow as developers. We shouldn’t forget that it’s our skill that makes us good though. It’s not the framework we use. And to say that using one framework or another is going to solve the problem of apps being hard to use isn’t accurate. The gains from using one framework or another are marginal compared to the gains you get from experience.

So, all things being equal, keep things simple. Complexity begets more complexity, which ultimately slows you down.

Until the fundamentals of building web applications change so that we don’t need to use markup, the simplest, best approach (in my opinion) is to use HTML and javascript for the UI and a scripting language on the backend.

Lastly, if you’re interested in some more of my thoughts on this topic, read a post I recently made title “Why are there so many Java web frameworks?”

Have at it everyone!

I was answering some questions about the TOC plugin today. I was asked where a certain fact was in the documentation. I popped over to the documentation, and realized that I could get a link directly to the relevant section because the TOC plugin adds named anchors into pages. So cool!

I love it when this sort of thing happens. You build something simple and then find it’s got all sorts of benefits you never thought of.