BigBlueHat

Remember these guys? BigBlueHat circa 2003

Designers love to design. Web manufacturers love to… build designs for designers!… among other things.

Over the past 4+ years we’ve found that XHTML and CSS have become second nature. Browser bugs and inconsistencies are much smaller bumps in the road these days. We know not everyone enjoys writing code as much as we do, so we thought we’d pitch in and help.

In the last few weeks we have done four sites for three different design firms. They sent us Adobe PhotoShop or Adobe Illustrator files and we sent them back working web sites—and averaged less than 5 days on the turnaround time!

We enjoyed the pilot program so much, we decided to set this up as a full service for web designers the world over.

If you’re a web designer who prefers designing to coding, or who would rather not be up late weeknights because “certain browsers” aren’t cooperating, or if you’re just plain tired of angle brackets, we’d love to help out.

We’ve posted the basic pricing information and instructions over at our Web Development page. We’ve also got an online order form to simplify the purchase process.

To see the outcome of the pilot program mentioned earlier, check out the screenshots below—you can click them to visit the finished sites:

SlopeSuds.com designed by Good Egg Studios

TheMidTownProject designed by Brannon McAllister

MarickMarketing.com designed by Liquid Inc. Marketing

I used to dream in XSLT if you can believe it. The largest web site I’ve built to date was built on Apache Cocoon. It’s an XML framework that lets you route incoming HTTP request through pipelines that generate XML, run through various XSLT transformations, and then serialize the output as HTML, PDF, or whatever. It’s a framework I occasionally wish I had time to get back into.

Brad and I have discussed using it in future versions of BlueInk. There are some newer XML technologies, though, that also look appealing, but there’s more research to be done on their stability and library availability for PHP. The one that interests me most is XQuery. It’s similar to XSLT, in that it transforms XML into something else, but because it’s a query language, it can munch data in fewer lines than XSLT and create non-XML-based results. I haven’t done enough research to be able to show you a use case yet, but hopefully once I move out the XQuery neophyte stage (whenever I find that time) I’ll post some code samples.

How are you using XML, XSLT, or XQuery?

Looking to build a new web site? or migrate an old one to a content management system? As of today, you can sign-up for a web site powered by our BlueInk Content Management System.

BlueInk provides a usable, focused interface for managing your web site’s content. Check out the feature list, screenshots, and demo for more information.

BlueInk comes in four different sizes, all available for instant setup on the BlueInk pricing page.

Brad and I have been discussing web architecture, programming methodologies, and frameworks recently. REST is certainly our architectural style of choice, and the edge of the diving board for the necessary shift in thinking gets closer daily.

During our discussions over the last several weeks, we’ve learned a few great things:

1. We want to build what’s next — not just buzz or hype, but what you want next or the next thing that would make your life easier.
2. It will likely be semantic, addressable, and built on technology from the early 1990’s — when TBL envisioned the Web, his initial idea was to make it both readable (as it is now) and writable (as it’s slowly becoming). Our objective is to fulfill that with the products we build. In addition, the more meaning (semantics) and “future-proofing” we can throw into the mix, the better for all.
3. Friendly, documented, simplicity should describe all we do — simplicity takes more education, intention, and forethought than complexity, but the payoff is unparalleled. Because education is needed, the more obvious and documented the functionality of a program, the more usable the program.

With those items in our heads, we’ve begun looking at the way we write, code, and manage our time and resources. Sometimes its painful to compare what you’d like to be doing with what you’ve done, but the value of the analysis is valuable beyond quantification.

What triggered this post was a quote I found today while looking for something else:

When people ask me what I do for a living, I say that I research what the web of the future could be. At that point, they ask me to give them an example of what that would mean for them. My usual reply is “if we are successful, the only difference you’ll perceive is that you won’t feel as constantly lost as you feel today”. At that point they smile, happy to meet a technologist who thinks it’s his fault, not theirs, if they can’t do something with his software.

No matter what technology or platform we build the future of the web upon, we need to learn how to write the software that delivers those smiles: anything short of that will be a failure.

from Piggy Bank, Cocoon and the Future of the Web

It’s a sentiment we share, and one we’re hard at work attempting to achieve. We’ll share more about how we’re getting closer to our goals as we work/fight our way to them.

Most web sites build with a Content Management System (CMS) do not send the correct “Last-Modified” date to the browser. The average CMS (include WordPress which runs this blog) show the current time as the date the page was last modified. The truth, though, is that the average web page or blog entry hasn’t been touched for some time (and certainly not in the last 30 seconds).

BlueInk, however, outputs the date the page was actually modified last. If you view the home page, for example, and click “Tools | Page Info…” (or the like for your specific browser), you’ll see “Modified: 02/13/2008 11:19:30 AM” That is, in fact, the last moment I made a change to that page. Yesterday, though, before we added this marginal but useful feature you would have seen whatever your current date and time are.

So why should I care?
While this may be the first time you’ve ever bothered to look at the page info for a web page, this data is useful to other web sites and web services that may interact with your web site. Search engines would be the first most obvious group of services to perhaps use this info. The growing number of “Web 2.0″ applications and even what are being called “Web 3.0″ or the “Semantic Web” applications could (and likely will) make use of that data.

We hope that our increasing “geekiness” about HTTP, REST, and other web standards will continue to pay off for our users in ways none of us may yet have envisioned. We’ll keep the future in mind.