Login or Register

RSS IconRecent posts in this topic

avatar
rambo on Dec 8. 2006. 1:17 pm
I thought I would make a suggestion about how to keep this software usable. I see many failures in the various software models that I should point out. I'll use a few applications as examples.

Mozilla Firefox: Keeps the application lean and allows for plugins. This plugin concept is a failure. Everytime the program updates (automatic update by default) most of my plugins are instantly outdated and turned off. This results in a half working application most of the user time. They also seem to have plugin overload. Sorting through all the crappy plugins to find a usuable one becomes more and more trying. A browser shouldn't be everything to everyone. It doesn't need music player buttons etc... or an endless stream of templates. Another problem with plugins is the "excited" developer of a plugin works on the first few releases of the plugin, then drops the project. I have seen few plugins keep up with the originating project. If sub developers have to keep up with bi-monthly release updates on their plugins, they are going to ditch out.

User customization. Another bad idea. Zen Cart uses what they call an overwrite system. A user can put custom code in a folder named after their templeate. Then when the core is updated it doesn't overwrite the custom code...in theory. Half the plugins for this cart overwrite core code and it eventually becomes impossible to keep up with the separations of code. A muddle mess. Therefore one becomes compelled to avoid updates. Therefore, any complicated hacks, plugins, code overwrites or templates will eventually fix the user in a state of not wanting to update for fear of breaking the application. This has been my experience with:
Firefox
OsCommerce
PHPProjekt
Mambo
Joomla
Zen Cart
MiniGallery
Mojo
Winamp

and many others.

You will be better off just slowly implementing, into the core, the features that people request. Don't spread yourself out too thin trying to make us all happy, and by all means don't allow open API for plugins. You have done an excellent job so far. I'd rather have you just updating the core, with the help of other developers, than a bunch of third party scrubs making a bunch of half-assed plugins.
avatar
sajseven on Dec 8. 2006. 3:31 pm
Don't listen to this! activeCollab needs plugin support and requires user customization. This makes as much sense as chapter two of 37Signal's book, Getting Real.

That chapter may have some truth to it, but taking away plugin support is like taking a Christmas present from a young child. User customization needs to be in place, because not everybody does the same thing. And simplicity is good, but features are even better, in some cases.

You wouldn't make a todo list with 15 fields - for sake of simplicity - but you wouldn't take away fields from a milestone - for sake of details and timing. you have to have the right balance otherwise you put people off - just like a website. If you make the website to "flashy" and "trendy", it will become slow and bloated - making it hard to navigate. But if you make the website too simple, you make people think that the company can't be bothered to put together a good act.

If you place yourself right on the "center-line", you'll notice that people will be more attracted to what you do. Your services matter - and so does your organization - so taking away core customization from activeCollab makes people want to use more bloated software - or pay for an alternative like Basecamp.

It may seem complicated, and it's true in some ways because you can't always get it right the first time, but if you let the community and average users tell you what they think, you'll have a pretty good idea of where to go - hence the reason for "open-sourcing" software.

It's a bad thing to take away these two features... and I can see where you're coming from, but maybe "re-wording" take away to simplify might make more sense.

Think about it...
activeCollab Team Member (NOT)
avatar
Ilija Studen on Dec 9. 2006. 1:31 pm
Hm, I am somewhere in between.

For instance, themes. Currently, they consist only out of images and stylesheets. IMO, that is more than enough to be able to customize look and feel of activeCollab interface. Some systems put templates in themes. That is bad idea and you already said how much horror can it make for users and developers. activeCollab will not support template overwriting by themes or plugins to avoid that kind of trouble, but you are free to restyle the look of the page.

Still, if it is really important for you to change something in templates you can do it on your own installation without making an upgrade process a headaches for rest of the users and developers.

Regarding plugins I think that they are really important for this project. The only issue is how much control should plugin developers have. Should they be able to overwrite core methods or bend over security settings? What is the purpose of plugin? To extend the system or to reinvent it?

Base idea is to have a good plugin support with a certain limitations introduced to ensure system consistence and security. Also, if activeCollab picks up eventually we'll introduce certification program that can be used by companies to identify plugins that fit well in the system and does not create a security or system risk.

@sajseven: What does this all have to do with Getting Real? You lost me there :)
activeCollab team member
avatar
rambo on Dec 9. 2006. 11:21 pm
sajseven:
Don't listen to this! activeCollab needs plugin support and requires user customization.


You have made no counter to the points I made. I'm trying to point out some flaws in the way applications and extensions have been handled. What is your specific answer to the problems that I listed? Why are 10 plugins on my Firefox browser currently not working? What is a good method for separating the core code from modifiable code? Why the need to open up design to non professional designers? I'm not really talking about plugins here. I'm talking about keeping an application useful, upgradeable, secure and most importantly focused. Sell me on the old way of doing business...I am listening.

My advice: Keep this thing on track. Establish the look and consider that your brand. If you have 300 different crappy templates out there and 300 different looks, then you have just diluted your brand. User customization of design is a fad. Is apple asking the kids what the next Ipod should look like? No.

Limit the amount of modification to the code, and or addition of plugins. I just one-click installed "gallery 2" on my host. Luckily the install handled the addition of 35 plugins. Could you imagine tracking them all down by yourself and then keeping them updated along with the core. This is the future. It is easy to accept the concept of plugins when you might only have around 10. But think of when there are hundreds and many of them are necessary. Now you have a very sloppy separation of code. Half of your app is plugins written by a disparate group of programmers who are writing sloppy work-arounds to get their plugin to work the way they need it. Their motivation is self centered and not collaborative. Bad way to develop an application.

Instead of plugins, take a consensus on what would advance the application for all users. If it is a benefit, then implement it into the next release of the core. Forget the plugins. Forget templates. Forget user modified code and hacks. Keep it all together in the core. Update the core. Maybe you can choose from a few different color schemes. Your design is clean and purposeful. Layout and design are just as integral to the success of an application as the code. More so. Why hand design over to a bunch of amateurs? You don't hand them the core code to futz around with.

Don't just go with the flow on this plugin/template/modified code paradigm. Question it. That is what building a better application is all about. Learn from the mistakes of the past. As importantly, learn from my mistakes and problems.

Anyone wishing to counter my statements, your opinions are welcome. Let's get a discussion of these issues on the table. Pros and cons.
avatar
decaf on Feb 8. 2007. 5:35 pm
Just to throw my 2 cents in. I think there needs to be an API. However the API should just be an easy way to get information out of activecollab and into other stuff and for other stuff to be able to put information in. As for the themes I think images and stylesheets is perfect. I want the API so I can write a little desktop app to sync the calendar and task lists to my PDA.
avatar
ryan.doherty on Feb 8. 2007. 6:21 pm
rambo: plugins are probably the #1 reason why Firefox has become so popular. It leverages the community and adds features that bring users over from other browsers. Without them, Firefox would be a pretty basic browser. I doubt the Firefox team could develop all the really good plugins while also developing Firefox.

I'm with Ilija, use CSS and images for themes. No, Apple isn't asking kids what the next iPod should look like, but kids are buying TONS of 'skins' for their iPods that 3rd parties are making.

rambo: Your problems with plugins in Firefox have nothing to do with the concept of plugins, the problem is how Firefox has implemented plugin compatibility.

An API is also a good idea. It allows people to create new products that use activeCollab, which might make them use aC even more. APIs and service based architectures is the future of the web. No app is an island.

It really feels like rambo has been burned by plugins and poor implementations of them. From what I've seen of aC's code and design architecture, I don't think we'll have the same problem with plugins in aC.
Topic is locked. If you have something important to say about issues discussed on this page please write at hi@a51dev.com.

RSS IconRecent posts in this topic