In the spirit of this thread that ended just over a year ago:
http://www.gossamer-threads.com/lists/bricolage/users/34814
When I was still at Denison, myself and a student took a lot of the suggestions from that thread and reimplemented most of our main templates. We were able to delete several un-needed templates with only minimal element re-configuration. Our code was much cleaner, mason-y and I'd like to think had a bit better performance at the end of the day. So to everyone who posted, thank you!
For the last few months, I've continued to think about either things I would have done differently, mostly along the lines of story and element modeling. Working with the Commonspot CMS has given me a different perspective on some things, and I want to make sure I put those thoughts on record before I forget. At first I was just going to e-mail Mike and Aaron, but then I thought others on the list might be able to benefit, too. Anyway:
1) Cut back on the story types. At Denison we had/have a standard page template, and then specialty templates for things like press releases (two types!), online forms, photo galleries, and tutorials.
The standard page was by far the most versatile, and by far the most used. When working with Commonspot, which among other limitations can't associate elements with a certain page type, I started thinking about the idea of a "super-Standard-Page" where almost every element or layout is available in the same story type that gets used 95% of the time. We were really concerned about enforcing layout when we built our story types, but the fact of the matter is that for a general page, users want to be able to mix and match elements as they need them on the page, and we ended up having to add in elements to specialty pages that we did not anticipate.
Obviously that doesn't work for everything. Things like a staff bio, or even a press release, or anything that has required, custom fields will need its own story type. But by the time I left, our tutorial story type was horribly redundant, as was our photo gallery story type. and I think the next time around I'd be more open to making the "Standard Page" even more versatile than we did.
2) Build a versatile Page Index Element - Using the Bric example templates, we created a custom Page Index story for each instance that we needed, each with its own template code. However, I think it makes a lot of sense to build a Page Index element that can be used with a wide variety of story types. We had custom fields for teaser elements, what we should have done is just used the description field that was already there. Then you could have a simple page index element that can be put on a standard page with various configuration options, and, using a code select field, work with multiple story types. Seeing the Page Index Element in Commonspot gave me the idea for this, and I think it would be fairly straightforward to implement in Bricolage.
3) Have a utility template for links. We had different template code for the links in our side navs, in-line text links, and other places as well. When I left we had the thought that it would be good to build out our link elements with the same or similar fields and used one utility template to output markup for them all.
Those are the things on my mind at the moment. I'd love to hear from anyone else who wants to share document modeling tips!
-Matt
http://www.gossamer-threads.com/lists/bricolage/users/34814
When I was still at Denison, myself and a student took a lot of the suggestions from that thread and reimplemented most of our main templates. We were able to delete several un-needed templates with only minimal element re-configuration. Our code was much cleaner, mason-y and I'd like to think had a bit better performance at the end of the day. So to everyone who posted, thank you!
For the last few months, I've continued to think about either things I would have done differently, mostly along the lines of story and element modeling. Working with the Commonspot CMS has given me a different perspective on some things, and I want to make sure I put those thoughts on record before I forget. At first I was just going to e-mail Mike and Aaron, but then I thought others on the list might be able to benefit, too. Anyway:
1) Cut back on the story types. At Denison we had/have a standard page template, and then specialty templates for things like press releases (two types!), online forms, photo galleries, and tutorials.
The standard page was by far the most versatile, and by far the most used. When working with Commonspot, which among other limitations can't associate elements with a certain page type, I started thinking about the idea of a "super-Standard-Page" where almost every element or layout is available in the same story type that gets used 95% of the time. We were really concerned about enforcing layout when we built our story types, but the fact of the matter is that for a general page, users want to be able to mix and match elements as they need them on the page, and we ended up having to add in elements to specialty pages that we did not anticipate.
Obviously that doesn't work for everything. Things like a staff bio, or even a press release, or anything that has required, custom fields will need its own story type. But by the time I left, our tutorial story type was horribly redundant, as was our photo gallery story type. and I think the next time around I'd be more open to making the "Standard Page" even more versatile than we did.
2) Build a versatile Page Index Element - Using the Bric example templates, we created a custom Page Index story for each instance that we needed, each with its own template code. However, I think it makes a lot of sense to build a Page Index element that can be used with a wide variety of story types. We had custom fields for teaser elements, what we should have done is just used the description field that was already there. Then you could have a simple page index element that can be put on a standard page with various configuration options, and, using a code select field, work with multiple story types. Seeing the Page Index Element in Commonspot gave me the idea for this, and I think it would be fairly straightforward to implement in Bricolage.
3) Have a utility template for links. We had different template code for the links in our side navs, in-line text links, and other places as well. When I left we had the thought that it would be good to build out our link elements with the same or similar fields and used one utility template to output markup for them all.
Those are the things on my mind at the moment. I'd love to hear from anyone else who wants to share document modeling tips!
-Matt