This is the first in what may end up being a series of posts wherein I try to educate myself about small-medium scale PHP web application development. I thought to do this because lately I’ve been excited about a project that is truly challenging me; it reminded me of when I began digging into CSS layout more in-depth and started posting here (2001). I gained so much from blogging through it, that it seems worth another try for my new endeavors.
First some “me” background:
I point these things out not just for context, but as a mini-disclaimer: I will likely report things that I’m doing that should never be done; hopefully I will learn from my mistakes, but please remember that I’m a novice. Corrections will be welcome with open arms.
I’m making a CMS, or really I’m making a site management tool. Over these last however-many years, I’ve worked-with, helped develop, and experienced many different tools for site upkeep. There are so many options out there – desktop apps like dreamweaver and contribute, CMS portal things like Typo3 and Mambo, and smaller-focus tools like the text editing script “Nimbletext” that Arturo, and I developed (with Chris) back when we ran Twinsparc. That’s just sampling, there are hundreds of options out there, with different focuses, expected audiences, etc.
Despite all the options, I see an opportunity for a new tool, one with a specific tool->developer->client expectation. I see a need for something that allows great flexibility for the designer/developer, without the need for either the developer or the client to absorb a complicated multi-layered navigation and user interface. One of the reasons I think tools like Tumblr and Soup.io are so exciting is that they quench the thirst for a meaningful type of simplicity – the type that allows me to do what I want by mostly getting out of my way. They both provide an interface that is created to anticipate needs and be powerful, without being a product of the structures used to create them.
So many tools are really just ugly, confusing database content editors. Really I think many of them would be better off turning off the “admin” section and just having people edit database fields directly.
That’s all the time I have for this initial post, more hopefully soon. Next time I’ll talk about the framework I chose to start with: CodeIgniter, and my initial setup.
Posted in Process, Web App Dev |
You can follow any responses to this entry through the RSS 2.0 feed. You can skip to the end and leave a response. Pinging is currently not allowed.
2 Responses to “Learning to make web apps”
October 6th, 2008 at 2:48 pm
And just why do you think some many have a “complicated multi-layered navigation and user interface”? Could it be that the subject is actually… complicated?
First, let’s not discount software like iWeb, RapidWeaver, or Sandvox, desktop drag-and-drop Mac applications designed to quickly and easily build small sites.
You apparently want something bigger. Take something as simple as asset management. You’d think that it’s as easy as uploading a few files to a directory. But no, uploading isn’t really the issue, as in a usable system you actually have to be able to FIND them again. So you’ve got titles and descriptions and tags and categories (which themselves need to be managed, selected, and edited).
Then there are thumbnails to be generated, as images need to be seen to be picked. (Add media pickers to the list.) And THEN there are scalability issues. Uploading to a single server? To an image server? Can you handle 100 images? A thousand? Ten thousand? A light news site or blog may need 5-10 new images a day, which could be 3,650 a year.
And that’s just one little-bitty slice of such a project. Just food for thought.
October 6th, 2008 at 3:14 pm
@Michael,
Excellent points; I think I should clarify.
What I’m building is not meant to be a replacement for all web upkeep tools – it’s not meant to serve the myriad of purposes/needs that so many tools provide. But I agree – in some contexts, more robust and complicated tools are absolutely essential.
The need/opportunity I see is for small-medium scale sites, which are often over-served by some of the larger tools.
In terms of desktop software like iWeb, it seems to me that most of them produce crap code, to greater or lesser degree. But really this points me to the lack of definition in my description of whom I imagine could use this tool I’m building. My thought is that this would be used by web agencies who need to develop highly custom-designed websites for clients with a limited number of non-technical folks tasked with updating the site. For these clients, cracking open a desktop tool is too much to ask, regardless of the quality of output.
Regarding your example of asset management: this is very good food for thought. I do agree that re-inventing the wheel is a waste of time, but in some cases lessons learned from the UI approaches of newer tools could inform and improve user experience and workflow.
I don’t expect to get it all perfect the first time. I do expect that there will be many features/aspects that I’ll need to trim for time and want to add later (maybe robust asset management!)
Regardless, I’m finding application development a fun road to travel down. Thanks very much for your input.
Leave a Reply