by John W. Long on July 19, 2010
Josh French and I have just committed a series of changes to Radiant that will change the way page children are created (you must be running on edge to see the changes). Instead of creating a child page immediately, the “Add Child” button will now present you with a list of page types. The goal of this change is to move the selection of page type to page creation. This change is essential for a number of other ideas that we are considering.
One benefit of this approach is that it allows a custom page type to change the way a page is initialized. For example, a page type could determine the initial values of fields or page parts.
In the future, this could also allow custom page types to easily make modifications to the page editing interface. So a Blog Post page type could add a dropdown to select the post author, or even list the comments on the post. Or an Event page type could add fields for the location and date.
We are looking for feedback on this change from the Radiant community. Add your thoughts in the comments below.
by John W. Long on June 7, 2010
I talked briefly about racking up your Serve projects in my previous article. But apart from the benefit of being able to deploy Serve on Passenger or Mongrel, why is Rack integration cool?
One benefit is that you get access to all kinds of middleware. Middleware is a software module that extends your server or web application with additional functionality. It’s called middleware because it sits between your application and the web server software. When a request for a file or resource comes into the server it first travels through each layer of middleware before reaching your application. Your application then sends a response back which again travels each layer of middleware before being served up to the user. As the request and response travel through each layer of middleware, the middleware can make changes to or even serve up something totally different. This is useful for adding features like logging, custom error handling, or gzip compression.
I my original article I showed you how to use Rack::ShowStatus and Rack::ShowExceptions to get handy error messages for your project. Today, I’d like to show you how to add Compass integration.
Never heard of Compass? Compass is a fancy new CSS framework built on Sass and it’s awesome. Among other things it provides a number of handy CSS3 modules that allow you to easily use a number of advanced CSS features. Without Compass and Sass this kind of stuff becomes pretty labor intensive to write.
Now Serve comes with built in support for serving Sass files, but it doesn’t know anything about Compass. To use Serve with Compass you will need to add the following lines to your config.ru file:
require 'sass/plugin/rack'
require 'compass'
Compass.add_project_configuration(root + '/compass.config')
Compass.configure_sass_plugin!
use Sass::Plugin::Rack
The first two lines are necessary so that the Sass Rack middleware is installed and the Compass framework is loaded. The next two lines tell Compass where your configuration file is located (in this case I’ve put it in the project root) and configure Sass using the configuration values stored there. The last line loads the Sass plugin as middleware.
Your compass.config should look something like this:
http_path = "/"
css_dir = "public/stylesheets"
sass_dir = "public/stylesheets/sass"
images_dir = "images"
javascripts_dir = "javascripts"
relative_assets = false
Your actual values will vary depending on how you are using Compass, but the key variables for the purposes of this tutorial are css_dir and sass_dir. In this case I’ve chosen to have the plugin generate my CSS in the public/stylesheets directory and store my Sass (much like Rails does) in the public/stylesheets/sass directory.
If you’ve separated your dynamic and static assets into the views and public directories (like I suggested in my previous article) you will notice that I’ve chosen to put my Sass and CSS in the directory for static assets (public). This is because the Sass plugin is designed to generate your CSS when the first request is made to your Serve application. Generated files are nice in production environments because they can be served directly by the Web server instead of by your application. This is in contrast to the way that Sass files are normally used with a Serve project. Normally, you would put your Sass files in views/stylesheets and they would be processed by the Serve Rack adapter on each request.
Here’s a Gist of the source code for this entire tutorial along with a couple of other goodies. Enjoy!
Hat tip to Chris Eppstein for his help with this.
by John W. Long on May 26, 2010
Serve is a rapid prototyping framework that I have been building for Web applications. It is specifically designed to make it easy to prototype Rails applications, but it can easily be used to prototype applications for any other framework. I’ve talked about the benefits of using Serve before, so I won’t cover that here, but if you are interested in learning more about Serve read, Serve: A Rapid Prototyping Framework for Designers.
Yesterday I released Serve 0.11.2 which adds built-in support for Rack. Rack allows a Ruby application to be deployed in any number of environments (Mongrel, CGI, Passenger, etc.). The good news for Serve users is that you can now deploy Serve projects much like any other Rails application.
Today, I’d like to talk about setting up your Serve project for deployment on Passenger (a.k.a. mod_rails). Passenger is an Apache/Nginx module that allows you easily deploy Rack-based applications in production environments. The benefit for Serve users is that with Rack and Passenger, Serve is much easier to deploy on a modern Web server. This will allow you to put your prototype project on a Web server that is easily accessible by your clients. Or, if you are on a Mac and you prefer to stay away from the command line, you can use Passenger and the Passenger Preference Pane to handle your Serve projects.
I’m not going to cover the setting up Passenger in this tutorial. That is already well documented on the Passenger web site. Instead I’m going to talk about how to convert your Serve project so that it works well with Passenger.
Passenger requires that Rack applications have a certain structure for performance and security reasons.
The Basics
We learn from the Passenger User Guide that Rack applications must have three things:
- A
tmp directory
- A
public directory
- A
config.ru file
The tmp directory is used by Passenger for the restart.txt file. You can notify Passenger that your Rack application should be restarted by updating the Last-Modified timestamp on the restart.txt file. The public directory is needed for static assets like images, javascripts, and stylesheets — in this case anything that is not processed by Serve directly. The config.ru file is a Ruby-based configuration file for Rack.
I’m going to suggest that we add one more directory:
In the views directory we’ll put all of the ERB, HAML, and special Serve files that are necessary for the prototype. Anything that does not need to be processed by Serve should go in the public directory. This includes all images, javascripts, etc. CSS files should also go in the public directory, but SASS or SCSS files should go in the views directory.
To create these directories and files, you can execute the following commands from the command line in the root of your project:
$ mkdir tmp
$ touch tmp/restart.txt
$ mkdir public
$ mkdir views
$ touch config.ru
Now move all of your existing Serve files into the views directory (ERB, HAML, SASS, Redirects, etc…). Be sure to preserve the existing directory structure. If you have a view_helpers.rb file that should also go in the root of views directory.
Once that is complete, move images, javascripts, and other static assets into the public directory. Again, be sure to preserve the existing directory structure. (If a file was in images/icons it should now be in public/images/icons.)
Rack Configuration
Now open up config.ru in your favorite text editor and insert the following code:
gem 'activesupport', '2.3.5'
gem 'serve'
require 'serve'
require 'serve/rack'
use Rack::ShowStatus
use Rack::ShowExceptions
root = File.dirname(__FILE__)
if ENV['SERVER_SOFTWARE'] =~ /passenger/i
run Serve::RackAdapter.new(root + '/views')
else
run Rack::Cascade.new([
Serve::RackAdapter.new(root + '/views'),
Rack::Directory.new(root + '/public')
])
end
Advanced users may want to modify this a bit to include other middleware or applications, but this configuration should suffice for the basic Serve project. I’ve included the Rack::ShowStatus and Rack::ShowExceptions middleware to provide pretty 404s, messages, and error handling. To turn off either of these features just comment out the appropriate line. Rack::Cascade and Rack::Directory are used to handle files in the public directory if Passenger is not used. This is useful if you are using Rack from the command line via the rackup command.
So that’s it! Everything you need to know to rackup a Serve project on Passenger.
by John W. Long on May 15, 2010
Last week I helped my friends at Terralien launch fullstackiphone.com. Full-Stack iPhone is a long-standing service from Terralien under a new name. Terralien has been doing iPhone interfaces for Web applications for some time now so we thought it would be appropriate to begin promoting the service in a more public way.
Terralien can deliver a lot of value to potential clients. Nathaniel Talbott has done a great job assembling a hand-picked team of top-notch developers and designers that are passionate about building successful businesses. If you are looking for a team that can build an iPhone application with an incredible Web-based backend, be sure to check us out.
by John W. Long on April 30, 2010
Page layouts are one of the most powerful features of Radiant. Layouts allow you to encapsulate much of the common HTML of a website into a template of sorts that is filled in with the information unique to each page.
Today, I’d like to share a couple of tips and tricks for making the best use of this powerful feature. These aren’t hard and fast rules, just a couple of the best practices that I’ve picked up over the years as I’ve worked with Radiant.
Use One Layout If Possible
Radiant allows you to create as many layouts as you want for your website. At first glance you may be tempted to create multiple layouts for your site that have a one-to-one relationship with the type of page you are creating. For instance, you may want to have a layout for your home page, one for your portfolio, one for your blog, etc. Resist this urge if you can. Depending on how your HTML and CSS are written, you may be able to get away with just one layout — even if the page that you are working on has a vastly different look and feel. The trick is to use conditional tags to switch parts of the layout on and off depending on the page.
Why is this helpful? It keeps all of the common code in one place and allows you to keep things DRY. It also minimizes user error and ensures that each page has the proper design, because a content editor never has to worry about selecting the proper layout. You set the layout once on the root page, and all the other pages inherit it.
Use Conditional Tags To Build Flexible Layouts
Radiant provides a number of conditional tags that make it easy to build smart layouts. Use them.
The most commonly used is tag is probably if_url (and its sister unless_url). This tag allows you to test the URL of the current page and show or hide content based on the condition. You can do an exact match on the URL by using the equals attribute, but I mostly use the matches attribute because it allows me to use regular expressions to match an array of URLs.
For instance, on WiseheartDesign.com I insert code for comments using the if_url tag with the matches attribute like this:
<r:if_url matches="^/articles/.+">
...code to display comments here...
</r:if_url>
If you are not familiar with regular expressions, this may look a little convoluted, but it is really quite simple. It basically reads, if the URL starts with “/articles/” and is followed by at least one character, then insert the following code. That last part is necessary so that the articles index page (which has the URL of “/articles/”), is not matched by the expression.
As you can see, the if_url tag is quite powerful for adding conditions to your layouts, but it has one significant weakness. Since it relies on the URL of the page, if you change the URL scheme for your website, you will need to remember to come back and update your layout. If your layouts are riddled with calls to if_url this may prove to be a bit of a headache.
Another tag that may be useful here is the if_content tag. You can use the if_content tag to test if a page has certain parts (or the unless_content tag to test that it does not). With clever naming of page parts you can get a lot of mileage out of this simple tag.
For instance, suppose you have two basic page designs for your web site. One is a standard two-column design with content and sidebar. Another is a simple single column design with no sidebar. By testing for the existence of the sidebar, you can actually handle both cases with a single layout:
<r:if_content part="sidebar">
<div id="content"><r:content /></div>
<div id="sidebar"><r:content part="sidebar" /></div>
</r:if_content>
<r:unless_content part="sidebar">
<div id="content" class="no_sidebar"><r:content /></div>
</r:unless_content>
The code above checks for the existence of the “sidebar” part. If it exists it renders two divs, one for the content and one for the sidebar. If the “sidebar” part does not exist, only the content div is rendered – this time with the “no_sidebar” class so that the single column version can be styled differently.
With a little a little imagination, I’m sure that you can see how the same technique can be used to achieve one-column, two-column, and three-column designs – all within the context of a single Radiant layout.
Use Snippets To Simplify Complex Layouts
Radiant snippets are designed to make it easy to share share common code between layouts and/or pages, but they are also useful for other purposes. The more complicated your layouts become the more you will find it makes sense to extract meaningful parts into Radiant snippets.
One purpose is to isolate complex or verbose code. For instance, you may want to put your Google Analytics code in a snippet. You will probably only enter this code once during the lifetime of your site, and there is no reason that it should clutter up your layout code.
Another purpose is to make content more accessible. I often put my navigation code in a snippet because as I update a site it is easier to maintain in isolation.
by John W. Long on April 8, 2010
Today I would like to announce the release of ToggleJS – a LowPro and Prototype-based solution for unobtrusively toggling elements with effects. ToggleJS makes it easy to create an advanced section on a form that slides out when the “Advanced” link is clicked, or to show more options when a certain check box is checked. And it does all of this with beautiful effects (complements of script.aculo.us).
View the online demo.
The way ToggleJS works is you select an element to be the “Trigger” element that will cause another another element revealed. You can chose a link, a checkbox, a select box, or a group of radio buttons as your trigger. You then add a rel attribute to the element that identifies an ID or group of IDs for the elements that should be revealed.
Using a Link as a Trigger
For example, the following code will create an advanced section that will only be revealed when the “Advanced” link is clicked:
<p><a class="toggle" href="#advanced" rel="toggle[advanced]">Advanced</a></p>
<div id="advanced">
... advanced options here ...
</div>
Note that I’ve set the rel attribute to “toggle[advanced]”. This is a special syntax that identifies the list of IDs that should be toggled when the trigger is clicked. (IDs appear between the brackets. To toggle multiple IDs separate them with commas.) In this case we are telling ToggleJS that the “Advanced” link is a trigger for the “advanced” div. By convention, toggle triggers are also identified with the “toggle” class (this is configurable). Also note that ToggleJS will take care of hiding the “advanced” div when the page loads.
A Checkbox Trigger
To create a checkbox toggle trigger, the syntax is almost identical:
<p>
<input type="checkbox" class="toggle" name="remind" id="remind" value="1" rel="toggle[remind_on]" />
<label for="remind">Remind me</label>
<span id="remind_on">on <input type="text" name="date" /></span>
</p>
In the example above, if the user checks the “Remind me” checkbox a date field will appear where they can enter a date for the reminder. ToggleJS is smart enough to recognize whether the checkbox is checked on page load and will hide or show the related element as needed.
Selects and Options
The code necessary to make this work with a select box is a little different. Instead of setting the rel attribute on the select box, you should set it on each of the options:
<select class="toggle">
<option>- none -</option>
<option value="1" rel="toggle[one]">One</option>
<option value="2" rel="toggle[two]">Two</option>
<option value="1,2" rel="toggle[one,two]">One and Two</option>
</select>
<div id="one">1</div>
<div id="two">2</div>
In this example, the select box is used to toggle the visibility of divs “one” and “two”, based on selection. Note that the last option, “One and Two”, displays both divs by specifying both IDs in the rel attribute.
Radio Buttons
The fourth and final way that you can use ToggleJS, is with a group of radio buttons. The code is actually strikingly similar to the code used for the select boxes:
<div class="radio_group toggle">
<p>
<input type="radio" name="numbers" id="numbers_none"/>
<label for="numbers_none">None</label>
</p>
<p>
<input type="radio" name="numbers" id="numbers_one" value="1" rel="toggle[one]" />
<label for="numbers_one">One</label>
</p>
<p>
<input type="radio" name="numbers" id="numbers_two" value="2" rel="toggle[two]" />
<label for="numbers_two">Two</label>
</p>
<p>
<input type="radio" name="numbers" id="numbers_three" value="1,2" rel="toggle[one,two]" />
<label for="numbers_three">One and Two</label>
</p>
</div>
<div id="one">1</div>
<div id="two">2</div>
The Wiring
Apart from the standard script tags for LowPro and Prototype, you will also need to wire in the appropriate LowPro behaviors. If you are building a Rails application, I’d recommend that you put this in “application.js”:
Event.addBehavior({
'a.toggle': Toggle.LinkBehavior(),
'input[type=checkbox].toggle': Toggle.CheckboxBehavior(),
'div.radio_group.toggle': Toggle.RadioGroupBehavior(),
'select.toggle': Toggle.SelectBehavior()
});
What this code does is associate the LowPro behaviors with the correct elements based on CSS selectors. You can customize the rules above if you want to use different class names or if you would like to tweak the behaviors with custom options.
For example, you can create an inverted toggle checbox by adding the following line to the Event.addBehavior call:
'a.inverted_toggle': Toggle.LinkBehavior({inverted: true}),
An inverted toggle link would hide the associated div the first time it was clicked instead of showing it.
You can also customize the effect used and handle custom before and after toggle events for the Toggle.LinkBehavior. For full details on the different options that you can pass the LowPro behaviors, consult the inline documentation.
There are also two configuration variables that can be used to customize the default settings for all toggle behaviors:
Toggle.DefaultEffect = 'appear'; # a string; the default is 'slide'
Toggle.DefaultEffectDuration = 0.5; # in seconds; the default is 0.25
Conclusion
ToggleJS removes the need to write custom code to toggle the visibility of other elements for many of the common use cases. And it does all of this in a clean unobtrusive way. You can learn more about ToggleJS, over at the GitHub project or view the online demo here.
Before closing, I’d like to thank the kind folks at MemberHub who sponsored the initial development of ToggleJS and have allowed me to release it as open source. MemberHub is a group communications platform for churches and other organizations.
by John W. Long on March 11, 2010
Over the years we have had many requests on the Radiant CMS Mailing List to add better support for conditional tags of some kind. Right now we have an array of tags for making conditional statements that are included in the standard distribution. The following is an incomplete list:
<r:if_children> <r:unless_children>
<r:if_content> <r:unless_content>
<r:if_url> <r:unless_url>
<r:if_ancestor_or_self> <r:unless_ancestor_or_self>
<r:if_self> <r:unless_self>
<r:if_parent> <r:unless_parent>
<r:if_dev> <r:unless_dev>
When Radiant was first released, we only had if_content and the rest were added as the need arose. We have considered adding generic support for conditionals, but every proposal thus far seems to require additional syntax of some kind. Chris Parish took a stab at adding generic support for conditionals at one point. His extension allows a user to type expressions like:
<r:if cond="breadcrumb matches /your regexp/">
or even,
<r:if cond="parts includes-any ['body', 'other part']">
To date we have avoided adding something like this to the core because of quibbles over the precise syntax. We also value the rigidity that the Radius attribute syntax provides. To be effective with tags in Radiant, a designer only has to understand tags, attributes, and nesting. Adding another strange comparison syntax on top of this seems needlessly complex.
Towards A Generic Syntax for Conditionals
While thinking about some of this today, it occurred to me that there might be a reasonable compromise that preserves HTML-like, attribute-oriented syntax while allowing a high degree of flexibility.
So without further ado, I would like to propose that we add generic support for conditionals to Radiant with the following basic syntax:
<r:if property="name" matches="regexp">
or unless,
<r:unless property="name" matches="regexp">
Above, the property attribute indicates a property on a page that a conditional operates on. (I will talk about properties in detail in a minute.) The matches attribute indicates that the property should match the given regular expression if the tag is going to expand. Additional attributes would include equals, nequals (for not equals), and nmatches (for not matches).
Now what exactly are properties? Properties would be a new first class concept in Radiant. There would be properties for all of the default page attributes (title, slug, url, etc.), but you would also be able to define your own properties with a class method on Page. So subclasses of Page could define their own properties or extensions could add properties to Page to declare properties that are accessible to all pages.
To declare a property you would define it within the class definition of a page like this:
property 'name'
By default, with no additional parameters this would assume that the property ‘name’ is a reference to the ActiveRecord attribute ‘name’. But you could also pass a block to calculate properties on the fly:
property 'full_url' do
'http://wiseheartdesign.com' + url
end
This would allow you to create constructs like:
property 'author.name' do
author.name
end
Of course, some additional sugar would make this much easier:
property 'author', :method => 'author', :attributes => [:name, :email, :website]
This would declare three properties, ‘author.name’, ‘author.email’, and ‘author.website’.
Once properties are declared you could access them within tag definitions like this:
tag 'if' do |tag|
page = tag.locals.page
property = tag.attr['property']
value = page.properties[property]
equals = tag.attr['equals']
tag.expand if value == equals
end
The bracket syntax would give tag authors easy access to properties on a page and make properties a first class concept in Radiant that extension authors can take to another level.
A Generic Case Statement
I would also suggest that there is room for a third type of conditional statement. We already have if and unless, why not case?
<r:case property="author.name">
<r:when equals="John">Lead Designer</r:when>
<r:when equals="Sean">Lead Developer</r:when>
<r:else>Core Developer</r:else>
</r:case>
And yes did you see that? case, when, and else allow us to avoid if, then, and else – another one of the commonly suggested features. We can keep it clean with single tags for if and unless, and allow case, when, and else for complex conditionals.
Suggestions, Addendums, Thoughts?
So there you have it. My proposal for adding a generic syntax for Radiant conditionals to the standard tag library. Any thoughts or comments from the Radiant community? Is this a can of worms or a powerful, much needed addition? Put your thoughts in the comments below.
by John W. Long on March 2, 2010
With all the buzz on the Web today about the necessity of good design for success, there has been very little discussion about matching the right designer to the right project. The way the word “designer” is used today is a bit ambiguous. It can refer to any one of a broad range of professions. From usability experts, to illustrators, to HTML and CSS specialists, to typographers, to user experience people.
To make matters worse, this confusion about the word “designer” and what it actually means often leads to hiring decisions that set projects up for failure. Hiring the wrong designer for your project can be akin to asking the wrong type of doctor operate on you. You would never ask a foot doctor to do brain surgery. Or, an eye doctor to remove your appendix. But the same kind of thing happens all the time in the design world and nobody blinks.
The truth is there are many different kinds of designers, and each is good at different things. Yes, some designers are generalists and their value lies in their ability to deliver consistently across multiple disciplines, but generalists rarely deliver the highest quality work.
So how do you find the right designer for your project? Especially if you don’t know a lot about design? Where do you start?
Recognize Different Designers Work Better In Different Mediums
One of the rookie mistakes you want to avoid when choosing a designer for your website is picking a print designer to do a Web designer’s job. There is a huge difference in the skills necessary to pull off a successful website design and the skills necessary to operate well in print. And the opposite is also true!
Since I primarily do Web design for a living I probably wouldn’t be the best person to design an album cover for your new CD or to create a brochure for your business. Could I do it for you? Absolutely! But again, I wouldn’t be the best choice. There are other people who can do this kind of work in less time and with better results than I can currently offer.
Why is this true? Because the medium that you ask an artist to operate in is just as important as the artist you choose. What do I mean by medium? The medium is the method or materials through which a work of art is presented. As this applies to design we generally use terms like print, web, or motion graphics (Flash).
Why is the medium so important? Because the medium that a designer is working in makes a huge difference in the quality of work that he is able to produce. You wouldn’t ask a sculptor to design a skyscraper, or painter to compose a symphony. All of these people can create beautiful things if you put them in their element, but get it wrong and you won’t get good results.
Recognize Designers Have Different Strengths
Along the same lines, the other mistake you want to avoid is selecting a designer that does not have a strong skillset for the types of things that will be necessary to complete your project successfully. Some designers are really good at illustration, use of photos, or color. Some designers are great at branding and logo design. Some at usability or total user experience (UX). Some are amazing at marketing and message.
On the same token, while a designer may be really good at one thing (say illustration), he or she may be terrible at another (say usability).
Why is this? A lot of it is about experience. Some of it, natural gifting. But a huge part of it is related to the designer’s personal passions. Designers tend to do well at the things they enjoy. Or, to enjoy the things that they do well. A good question to ask a potential designer is does your project fall into the category of the things that he or she enjoys? If it does you will probably find them quite knowledgeable about the things that are necessary for your project to be a success.
The last thing you want is to end up paying someone a lot of money to do something that they are not good at. Consider a potential designer’s strengths and weaknesses when matching them up with your project.
Recognize Some Designers Have Different Appeal
Another thing to consider in your search for the right designer for your project is the appeal that their personal style has to your target audience. Some designers are good at tailoring their style to the audience, but others are not. This isn’t necessarily a bad thing. Many designers are very successful at producing a certain look that their clients value. As you are evaluating a designer consider the diversity of his portfolio, or, conversely, the consistency. Is their personal style something that would appeal to your target audience? If the answer is no, move on.
Other Things To Consider
Of course, there are many other things to consider as you look to hire a designer for your own project. How well do they communicate? Do they connect with you personally? How responsible and honest are they? But the points listed above should give you a framework for considering the value that they may be able to deliver in terms of design.
If you can afford it you may want to engage multiple designers. One to work on each of the individual components of the project. For example you could engage one designer to help you develop a good logo and brand for your company (or project), another to work on the marketing and emotional appeal of your website, and another to work on the user experience.
If money is tight, you may want to engage a designer that is more of a generalist rather than a specialist. After all, there are times when it’s just more economical to go to a family doctor instead of a specialist. But know the difference and hire accordingly.
And don’t forget to ask probing questions like the ones mentioned in this article. It is your money, business, and reputation that is on the line.
by John W. Long on February 24, 2010
My good friend and fellow designer Brandon Mathis has put together a wonderful little default avatar package that is available for free on his website.
Brandon and I had the good fortune of being able to work together on MemberHub.com back in 2008. MemberHub’s design needs were growing beyond what I could handle at the time so we needed someone to help us power through many of the features we were working on. An all around great guy and extremely competent designer, Brandon was just the sort of person we were looking for to assist us.
So it was while we were in the midst of things working on MemberHub that Brandon took the time to improve the MemberHub default avatar. The default avatar is the picture that every user gets to represent them if they haven’t uploaded a photo on MemberHub.com. At the time we were using a lame question mark avatar reminiscent of the old Facebook default avatar. We wanted to make the avatar a little more personal. As we looked around for a good free option we discovered to our chagrin that there really weren’t any. We both thought this was a shame, so Brandon spent his own time to create a default avatar set that we could use on MemberHub.com that he could also release for anyone to use.
The result was Fancy Avatars. A default avatar set that can be easily customized to suit your needs. The set includes male and female avatars, and the orignal vector source image (a Fireworks PNG). Fancy Avatars is licensed under a Creative Commons Attribution license so it is free to use on both commercial and personal projects.
Check out the demo page or download the set now.
by John W. Long on February 17, 2010
I don’t know if this is even possible, but I wanted to put it out there to at least stimulate some discussion and perhaps even jolt some of you to action. I’m issuing a public call for designers interested in contributing to Radiant CMS. Effective immediately.
No, I’m not looking for resumes, portfolios, or recommendations. I’m looking for people who are good at what they do and get it done. Opinionated, kind-hearted folk who communicate well and can handle criticism. If that sounds like you, here’s how you can get involved…
Fork the Radiant Prototype Project on GitHub
We’ve created a prototype project on GitHub for Radiant that makes it easy to jump in and contribute. To get started, fork the project on GitHub, clone it onto your local box and use Serve to get it running so that you can start making changes.
New to Git or GitHub? Check out the GitHub learning site and help system.
New to Serve? Read the introductory article and watch the screencast at the end. The great part about using Serve for the prototype is that it allows us to focus on just the HTML, CSS, and Javascript. Once we get things worked out in the prototype they can easily be ported over into the application.
Pick An Issue
There are a number of issues related to the interface on the GitHub issue tracker, if you are looking for something simple start there. There’s not currently a lot of design related issues, but here’s the low hanging fruit:
There are also a number of unfinished things in the prototype that are just waiting for someone to polish them off.
Or, Work On An Extension
Maybe you aren’t interested in working on one of the core features in Radiant, but you would like to work on a Radiant extension. If so this is great! There are over 190 Radiant extensions in the extension registry that add support for all kinds of things. Things ranging from “version” “control” to “asset” “management”. Most of the extensions have been written for 0.8 and below. We are just getting ready to release 0.9 and the lack of polish on some of the extensions is really starting to show. We need folks who are good at design that can help extension developers bring their extensions up to snuff.
To work on an extension, you can either pull the HTML from the extension into your fork of the Radiant prototype and work on it there, or work on the extension inside of an existing Radiant project. The second option takes a bit of know how, but getting an extension developer to give you a hand with the setup process shouldn’t be too difficult. I’ll talk a little more about getting help at the end of this article.
Or, Make Something New
To date almost all of the work on the Radiant interface has been done by myself and a couple of the of the Radiant developers. I am very interested in hearing other designers ideas about how the interface could be improved and made more user friendly. In particular, I feel like we have a ways to go before we are competitive with products like Wordpress on the UI level. Right now the interface works pretty well for power users, but we need to do a better job reaching out to first time users. More inline help in the interface is important, but we also need to build a real help system. I’m visualizing something that would open in a separate window.
I’m also interested in any thoughts people have on asset management. I’m a big fan of the approach that page attachments takes, but I also see room for the way papperclipped has implemented the Mephisto-style asset bucket approach. Ultimately, I want something that is a bit of a combination of the two. And I want it to work well even if you don’t have support for image thumbnailing installed on your server. This means having alternate views without thumbnails. I would love for someone to take a stab at merging all of these concepts on the UI level. It needs to be slick in every way.
If you are feeling adventurous, you are also welcome to work on something completely new. Redesign an aspect of the interface or even the whole product. Fresh ideas are important if Radiant is going to continue moving forward. Who knows. You might just find yourself at the center of the next major release.
Or, Work On The Marketing Side
I’ve got some ideas for updating the Radiant site itself to be more competitive with with other sites. If you are interested in helping here, contact me directly. The original design for the site is a couple of years old now and it could use an serious update.
Not Ready To Work In The Prototype?
Maybe jumping right into the HTML is not your thing. I hear ya. I often like to work out my ideas in a graphics editor like Fireworks or Photoshop before getting too far. If that is your thing, check out the Radiant mockups project on GitHub. You’ll find the original source images for much of the Radiant interface in there. You heard me right, the original source images! They are in Fireworks PNG format, which means that if you open them in Fireworks you will be able to edit them in all of their vector goodness.
If you are savvy enough, fork the mockups project on GitHub and add your new mockups to the fork. GitHub is a great way to share your work and it will make it easier for people to view and use what you are working on.
If working with Git and GitHub is too complicated for you, you can still download the original source images. On GitHub, browse over to the Radiant mockups project, then open the page for the graphic that you want to use, and click “raw” (in the gray bar underneath the filename) to download the image in its original format.
Getting Your Changes Approved
OK, so we’ve covered a lot of the technical challenges on contributing to the design effort on Radiant, but I’d like to address one of the most important aspects this whole process: getting your changes approved and merged into core.
This is a tricky one to answer.
On the one hand Radiant can desperately use the help of other designers. On the other, there is no question that Radiant has benefited from the opinionated and sometimes heavy handed oversight of one designer (namely me). I don’t plan on relinquishing my role of “Lead Designer” on the project any time soon, but it’s also becoming clear that I can’t do everything that needs to be done.
So here are some tips for working with me to get your changes approved:
- E-mail the developer list. Before you get too far on a feature, send an e-mail to the Radiant Developers list and look for feedback from either Sean Cribbs or me. (Sean is the lead developer of Radiant.)
- Blog about what you are doing. Help us understand your reasons for wanting to change the Radiant interface. Outline the changes you have made or what you would like to do. And don’t forget to tell us about your article on the developer mailing list.
- Post screenshots. I am a very visual person. Posting screenshots will give me a much better idea of what you are working on. Who knows, I may even give you a return volley of screenshots for how I would suggest that a given feature should be implemented.
- Work with the existing design. If your design departs from the current look and feel it will be very hard for me to sign off on what you have done, no matter how awesome the feature is. I don’t want to discourage people from seeking to address problems with the current look or feel, but significant departures greatly increase the chances that your changes will not be approved.
- Persevere. If I don’t like what you have done on the first or second pass, keep at it. Find a way to work with me. I know I’m an ornery fellow, but find a way to work with me. I’ll do my best to do the same on my end.
Also, don’t forget that even if your changes are not merged into core, someone else within the Radiant community may like what you are doing enough to make an extension out of it. There are plenty of extensions that are extremely valuable that will never be part of the core distribution. This is part of Radiant’s appeal. It is not the CMS that does everything out of the box. It is the simple CMS with a solid core.
A Word On Open Source Design
Open source projects have a reputation for being poorly designed, but I don’t believe it has to be this way. Developers have been working on the problem of “collaboration with anyone” for a long while now and have proven that it can work. As designers I think we are behind the curve a little, but I see no reason why we can’t make it work as well. All it will take is a little commitment, humility from everyone involved, and a lot of hard work.
So what about you? Do you think this can work for Radiant? Are you willing to give it a try?
