Things MeTal needs to do

By Serdar Yegulalp | 2015/12/09 14:04

Before I get back in the saddle with MeTal (ETA: Jan 2016), I thought I'd post this.

Any decent software project has a design document of some kind, where details about the project's requirements are laid down. Here's my primordial version of same for MeTal, where I lay out some major goals and how I plan to fulfill them.

Be easy to set up and use.

MeTal is a product, not a project. Both my other users, and my future self, will thank me for this in the future. Using it should feel like a commercial piece of software whenever possible. I'd rather have a small but well-polished feature base than a large but ugly one.

Run fast -- or at the very least, not let long-running activities interfere with the user's workflow.

Most people are not going to be running MeTal on dedicated VPS boxes. Odds are they'll be running it on low-end shared hosting -- just like the server this page was most likely delivered from! That means bearing in mind how operations have to be asynchronous and stateless. Long-running operations should not be in danger of timing out because of some Web host's stingy resource allocations.

Work on sites with minimal resources where possible.

As hinted at above and previously in this blog, my own web host is nothing to write home about. That makes it a good environment to test in. MeTal should run on least-common-denominator hardware and software.

Be friendly to the designer, the editor, and the coder. Treat everyone like a user.

This goes back into the first point outlined above, but I think the first and last people in the list I made there often get overlooked. Designers and coders are users, too, just as much as plain ol' bloggers are users.

Be backwards compatible.

Major point releases to the program should not break continuity of use. At least one major point release should come and go before any major functionality is deprecated (e.g., a template function).

Be forward-looking.

This shouldn't consist of adding new technologies just because they've come into existence, but not being unfriendly to them when they do. For instance, I know I'll want to add support for Markdown, or a CLI; those are all planned additions.

On the other hand, while we might rework the front-end UI using some of the new-fangled Web widget toolkits that are out there, I'd rather wait for that scene to settle down and prove itself before attempting to build anything on top of them. HTML5, CSS3, and Boostrap are more than good enough for now.

A lot of how the program is extensible will be by way of plugins, but I want to make sure how plugins are supported for this is robust -- e.g., that APIs are exposed in such a way that wrapping them in a plugin's functionality isn't unduly difficult.

Be something that keeps people happy.

This is a tough one to quantify, but I'll put it this way: MeTal needs to be a product where people stay with it because they want to, not because the pain of switching away is too great. People should stay with it by choice.

I might not be able to do anything about the gravitational pull exerted by the likes of WordPress due to the sheer size of its ecosystem, but at least I can make MeTal good on its own terms.

Tags: features goals whys and wherefores

comments powered by Disqus