• Services
• Philosophy
• FAQ
• About
• Contact

If you asked this question, you're already doing better than most people.

First, decide what it is you want your site to do. What content do you intend to offer? Will it need to change regularly? Will you need a site which expands, or which remains the same size?

Second, think about websites you may have seen in the past which offer content in a similar way to what you want. Take a look around the Web and see if there are any sites which do this if you can't think of any off-hand. The Internet is huge and we're willing to lay odds that you'll find another site which will fit the bill. Even if one site doesn't offer everything, maybe you'll find parts of several sites which do the job.

Third, imagine yourself as a stranger visiting your site for the first time. What will they see (the exact look of the site is less important that what content they'll be able to find, and how they might go about using that content on your site)? What do you want to communicate to them? What should they get out of the experience?

If you've got notes on all of these things, you're ready to go. You may not know that what you want is a blog with an attached wiki and tree-posting capabilities, but you'll have the information to let you make informed decisions when we discuss.

And then contact us. We will answer all basic inquiries, and if your inquiry looks like it might be more than basic, we'll answer the basic parts and then talk options. Even if your inquiry leads you to purchase a system from someone other than us, we want you to have what you need, and we're happy to tell you what that is likely to be. Hopefully, if you do decide to go with someone else's system, you'll still think of us when it comes to getting that system to work.

We believe in minimalism of web design. We've added a few bells and whistles, but mostly this site is about us, not about pretty pictures. We're not graphic designers.

Also, there is a tendency on the Web to believe in form over substance. We'd like our site to be accessible to the maximum number of people, so we haven't used strange fonts, odd colors, or inaccessible images. The Internet is not print media, and thus we must allow greater flexibility. Any bells and whistles we've added have been for convenience, and we've tried to make sure that they won't affect your experience if they don't work.

There are two varieties of this question. The first comes about because people follow the advice listed above and find a site with pretty much exactly the kind of system that they want. We welcome this kind of question, because it helps inform us of what you're looking for in a CMS. If the question has to do with the function of a site, and not its form, chances are good that it falls into this category, and we want to hear it.

The other variation is people who see cool widget X on a site and want to know if we can do that. Usually, this has more to do with the form of a site, the way content is presented, not with the content itself. We don't discourage this kind of question either because it can give us information, but depending on what is being asked, we may simply have to say, "No, we can't because we aren't [Insert Technology] gurus." We will make every effort to accommodate your needs, but sometimes we are asked to duplicate code which is site-specific and was developed by a huge company to the tune of millions of dollars. If you want us to duplicate something that Microsoft or Google have done, chances are good that you fall into this bucket and we might have to tell you we can't do it. Sorry.

We like to think that we do, although we do the part that gets less press. Without CMSes and IA, the web as we know it wouldn't exist, but people are much more enamored with the flashy things.

That bit of fluff aside, we don't specialize in web design because there are many people out there who do and who are better at it than we are. We know enough to understand the code they write, but we can't keep up with web standards in three different languages on a myriad of browsers while at the same time keeping up with the back-end side of things. We also know enough design principles to discuss the visual design of sites, but we aren't artists or graphic designers.

We will discuss your design needs and, if they seem to be within our capabilities, we will certainly consider taking them on in addition to your CMS needs. It's something we decide on a case-by-case basis, so we can't say exactly what it is we look for. If your design ethos and ours mesh, your site will likely be simpler and contain more content and less fluff.

No. We don't have enough experience, and the hosting market is fairly volatile. We can make some general recommendations about what to look for, or offer our personal experience with several hosts, but we won't get a commission for it if you sign up with anyone.

We use PHP and MySQL for our back-end work. Both are industry standards, both are Open Source, and both play well together. Chances are good that any web host will offer them and they aren't proprietary.

We prefer Linux/Unix-based platforms simply because they run both of the above and Apache, which, while we could live without if we had to, we also like. We are not Linux gurus, nor do we hate Microsoft, we simply have had better luck with Apache. Given the fact that it too is an industry standard, it's hard to argue.

For any front-end work, we try our darnedest to write standards-compliant XHTML, but occasionally that rule must be fudged. Web standards are... interesting. We are conversant in CSS and we dabble in JavaScript. If you have specific technological needs for whatever reason, we will discuss them.

No. This may seem like a startling admission, but it's actually perfectly logical. If you want a website, the content of which changes very irregularly if at all, the benefit you get from a CMS would be minimal compared to the outlay of effort/payment. We can write the site and change it quite easily without involving an extra layer, and if your project seems like it would be this way, we will tell you, even though it probably means we don't get the job. Over-engineering things is as big a mistake as under-engineering them, and is significantly more expensive.

That being said, building a CMS for this site would be much more simple than most, and if you were we and you wanted this site to be manageable, we would certainly build a CMS for you based on this model. All these questions are things which will come up as we discuss the project, and we won't force you into a decision one way or the other.

There is some PHP employed in the site, and we have done some IA with regards to navigation on top of the IA we did to figure out what information should go where. If/when we make the jump and create a CMS for the site, one of the first things it will undoubtedly do is allow us to add questions to this FAQ. This is one area where a CMS would simplify things extremely.

Not at the moment. If it happens, it'll be a blog, and then we'll have to alter our answer to the above question (as well as this one, obviously). We don't have time for any of the other things. And let's face it, coding our own blog would be good advertising.

No, because in order for the demo to be useful to you, it would have to be insecure. Also, there's no way we could hope to demonstrate the sheer breadth of the CMS world. And part of the thing about CMSes is that the sites which they manage shouldn't look any different from sites which are hand-coded. So we could lie and say that this site was our demo, but you'd never know... except that we just told you it wasn't.

Our contact page is designed to foil spammers by the use of JavaScript. Unfortunately, that means that people with older browsers or with JavaScript turned off or severely restricted may have to go through an additional step to email us.

We could have used a contact form, but we've found them cumbersome in the past and too easy to abuse. We like to be able to reply to your email, and we want people who aren't spammers to be able to see our email, so we chose this fairly elegant solution. We're sorry for any inconvenience it might cause.

That's not a question. But if there's something we haven't covered, contact us and ask. An informed consumer is a better consumer. We'll probably add the question to the FAQ, so you'll be helping others as well as yourself.

How many stereotypes does it take to do a stereotypical task?

M+N, where M is the number of people it would typically require to perform the task, N is some non-zero number, and Humor is inversely proportional to N. Solve for Humor. Show your work.

Defining "Content Management System" is a bit like defining "mode of conveyance:" it means different things for different purposes. The most general definition is (can you see it coming) a system for managing content (no kidding). For our purposes, Content Management System (CMS) means software which allows you, the owner of a website, to change and update content on your website without having to know the nitty-gritty of web design.

A CMS can be anything from the back end of a blog, which would allow you to create and edit posts and would then store those posts and list them for your viewers in various ways; to a complex site where every piece of content, from text to media, is able to be changed by the owner of the site. CMSes provide a layer between the site and you to allow you to manage your content in a more user-friendly way. They also allow data to be centralized in one location and then inserted into multiple places in different ways (although that involves the Information Architecture of the site as well)

If defining CMS is bad, defining Information Architecture (IA) is worse. There is no accepted standard definition because the field is still so new. Add to that the fact that much of the time, IA is overlooked or simply happens ad hoc, and you'll understand why we flinch at this definition.

For our purposes, IA is the information design of the site: where information will be placed, how it likes together, and how it interrelates. It also means designing data storage in such a way that there is minimal duplication, and that only the minimum necessary data is stored, while making it possible to make changes to one piece of data that are reflected throughout the site.

It's unfortunate that so many people fail to consider IA, because it can be what makes or breaks a site. But because it integrates with so many other aspects, including the design of the user interface, the design of the CMS, and the creation of content by the owner, it is often overlooked or undervalued. Rhino Plus Facile is dedicated to considering IA and making it work for you. It is an integral part of our design process and thus we are able to deliver sites which require less editing to make the same overall changes. That's where you'll appreciate IA the most; when you want to make a change to every single page on your site, and instead of having to make hundreds of edits, you'll only have to make one.

A blog, short for web log, is a ubiquitous CMS which allows one to post an online journal, divided into posts, often organized by topics or dates. Depending on what blog you mean, it can include many other things as well. It is often maintained by a single user or small group, rather than being open to anyone to join and add content.

A forum is the modern version of a bulletin board, where multiple users can have discussions, create content, and do various other community-oriented things. Forums can be as simple as a list of posts with the ability to reply to other posters, or as complicated as a complex tree-structure, organized by sub-forums, with various bells and whistles. Forums are sometimes used for small groups, but often are open for anyone to become a member, although fees may be charged.

A wiki is a CMS which allows a group to collaboratively edit content. It is organized more as a website than a discussion board, so pages may link to other pages and be edited by anyone allowed to do so. Some wikis are open to the public, while others are used by select groups for collaboration. The wiki philosophy is far too complicated to go into here, but suffice to say that not all wikis must be open to changes by anyone; a wiki is merely a tool frequently used for that purpose.