David Dyess .com

This installment of the 10’s Series is about enhanced GUI features. I think the two items I’m going to discuss are possible now in most frameworks and that is why I don’t think they are far-fetched. In some ways I feel we are nearing the home stretch of Web 2.0 and approaching whatever they call it next (2.5?). Web 2.0 has been about interaction and using the browser as a platform for applications, moving the web closer to the desktop. It’s meant other things as well, but I think the summation covers a lot of 2.0.The advent of Chrome OS (as well the platforms that inspired it) and the push for HTML 5 are shoving us ahead into the next.

Web OS / Web Desktop /etc.

There are lots of Web OS’ in the wild today, EyeOS is probably the most notable one. Web OS’ haven’t caught on as much as I thought they would a few years ago when I heard of them. I think we were waiting for the ‘Cloud’. I can see a web page styled as a desktop used several ways, but I think it is a logical step in the evolution of web interfaces. Imagine logging into your web site and having a desktop OS-like sitting in front of you. You have a desktop to save shortcuts to work or your favorite tools, you have a Start-like menu to navigate your site’s tools and features. You open your articles listing and a list of icons opens in a window on your desktop, each an article. You open your images or media folder and you see thumbnails instead of the old list of links. You minimize your images folder, which is now a tab on your taskbar, and open a new article. You type it up, drag an image into it from your images folder and save it. You then open your web site in a new tab or in a browser window on your web desktop and see the article on your home page.

A web desktop as an administrative interface to a web site seems like an intuitive way to manage a web site. It not only makes managing a web site more familiar, but it also opens it up to a whole new set of capabilities. I can also see the desktop being useful on the user side of a web site. A lot of people may think this seems silly and just a fad, but when I said, a few years ago, Google would be building a web-based operating system, they thought it was silly as well. Now Chrome OS is coming up quickly and it uses AppEngine, a web-based application platform. Here, I’ll do it again, Facebook will be building a web desktop. The PHP frameworks that hit it big in the 2010’s will have capabilities to launch web desktops and the apps to use on them.

Web IDE

I’ve been grappling with this one for a while now. We have 3 client computers in my house and I spend almost equal amounts of time on 2 of them. I try to use them both for development, using Eclipse and SVN, but something seems to always go wrong or I forget to update my repo. I have found tools like PHPAnywhere, but I don’t want my development code on someone’s server. What I want is an IDE, like Eclipse, built into my web site. I doubt I’m the only person that thinks an IDE built into a framework (or at least on top of the framework) would be useful and a huge boost in project development efficiency. Implemented effectively, a web IDE could virtually replace conventional version control tools. At the very least, an IDE could supplement version control enough to ease the headaches that come from managing repositories for large projects.

To wrap it up so far, a 2010’s framework should have:

• Powerful template system for the web designer (1)
• Dynamic “Core” (1)
• Flexible low-level configuration (1)
• Web-based Desktop
• Web-based Integrated Development Environment

To be continued…

I had hoped to have released a Clay alpha by now, but time seems to never be on my side. I, also,  keep finding better ways to do some of the, even simple, things that make Clay work. I have been slowly moving forward. I have the week of Christmas off from work so I plan to make a little extra time for development in between spending the extra time with my family. I think, if time gets a little more on my side, we may have a late Christmas present coming around New Years’.

I haven’t had a lot of time to try it out, because I just received the invite, but I finally got it    Doesn’t look all that impressive on the surface, but maybe that’s because I need more friends on there. If you want an invite (I have 8 left), comment or send me an email.

Maybe I’ll ave more time this weekend to give it a spin.

Interesting article on Forbes.com about climate change.

I don’t like the BCS, even as an Alabama fan. I don’t know of many people that think a top 8 playoff wouldn’t be better. The season wouldn’t last any longer and there would finally be an undisputed champion. Cincinnati, overall no. 3 in the poll, actually beat Texas in the computer rankings (.9300 to .9200), but was voted 4th in the human polls. TCU, which has the most outspoken fans this year, took the no. 3 spot in the human polls and no. 4th overall. All 4 teams are undefeated, along with Boise State with came in 5th behind the 1-loss Florida Gators.

Round 1 of the playoffs would have been:

Alabama (1) vs Ohio State (8)

Texas (2) vs Oregon (7)

Cincinnati (3) vs Boise State (6)

TCU (4) vs Florida (5)

No one knows what round 2 would look like…other than a step closer to a single undefeated national champion.

Alabama 32 – Florida 13

ROLL TIDE ROLL!!!

I’ve been trying to be a little more open with what I’m working on for Clay, hence the ‘Framework for the 10s’ series. So…here’s some brainstorming as a blog.

I’ve been trying to figure out how to separate the use of APIs and applications as backend and frontend (with backend capabilities). I also want to leave the framework open enough where developers can create their own tools that easily override Clay’s default ones, but most of those tools will have a GUI, which means they have to be an application, and therefore have to be called explicitly using app::load(). What I’ve come up with is adding an app::alias() function to call a generic application name, which the actual returned application/application function can be specified by a configuration setting. This would not only make it easier for developers to migrate to their own tools, but would likely ease Clay upgrades down the road. Of course there is a way to explicitly deny an API of having a GUI, but I’m trying to make it easier to avoid the temptation and not close off the option if it is a must.

One of the many other concepts I’m trying to perfect is the use of extensions and plug-ins in Clay. What I’m considering is classifying all external API and Application functionality as a Service. Each would register their services with the framework on installation and the framework would use the appropriate or specified service when requested by another API or Application. Services would include direct content plug-ins, blocks, extensions, hooks, transformations, etc. Once again, this implementation would leave developers with the most choices and not close them off to only the functionality currently available within the framework.

Finally, for the sake of this blog, I’m considering using a packages approach to ‘Core’ installations. The Clay ‘installer’ does not actually have any database requirements, instead it uses tools provided by APIs and Applications, which means it is entirely customizable (it is actually it’s own web site, using Clay’s multi-configuration feature). To go a step beyond that (and for the sake of sanity), packages would allow a developer to create a package with set requirements and a functionality set to go with it. For instance, I could create a Message Board system (like PHPBB) using Clay’s APIs as the backend and provide a package that would tell Clay which applications/APIs/etc it needed to run. Clay would then set up the package from its installer and ensure all dependencies were met, as well as install the applications and APIs.