[suggestion] Remove theme capability for SMF 3 (or earlier)

Started by bloc, March 27, 2011, 05:42:20 AM

Previous topic - Next topic

bloc

Ever since the release of SMF 2 we have seen a good amount of themes get released that rely mostly on the Curve layout - nothing wrong with that in itself - but less and less themes provide a different basic layout than said Curve. Some have dared to do it, but its mostly been futile. People that create themes don't want to code/change anything but index.template most of the time. Maybe occasionally Boardindex and Display but thats it.

So why is that? Lack of knowledge to code? Perhaps...but I think the bigger reason - because coding can be learnt - is that mods that need to change templates will no longer install if you change them in custom themes. So they stay away from it and focus on the CSS instead.

That leads to the conclusion that changing templates for custom themes is a rare thing, and having a system to are able to do it, is effectively under-used.

So I suggests SMF 3 ships with NO THEMES capability whatsoever. Specifically:

  • all templates will be located in default theme only(where site owners can change those if they dare) and only leave  variations to play with.
  • variations use only CSS.
  • Default theme provides a hook to add custom layers for those that need to add into index.template in any given variation. Preferably after the body layer, so a new framing could be added. Possibly also separate the pure framing elements of Curve, so they are easily replaced. In either case: it can be changed with CSS too..so its not *really* necessary.
With these changes you gain the benefits of:

- every mods will install without problems(at least not due to custom theme code).
- CSS changes are maintained during upgrades.
- No need to provide a big section for themes, only the variations.
- "current theme settings" will be a thing of the past, since ALL settings apply to default theme anyway.
- easier previewing since only the CSS file - and possibly hooks - will be previewed.

The downsides are of course:

- no truly unique layouts possible other than by modding the templates, which could be argued being better since less new theme code will be inserted. A whole theme is potetnially repalcing bits that don't need replacing.
- site owners that needs custom themes will need a designer to hack the default theme - but again, that could be a mod rather, applied after upgrades for example.

* * *

I hope you seriously consider this for SMF 3(or earlier) since you would move forward in the mod/theme dilemma. It might introduce new problems too, but that won't outweigh the advantages by changing the system.

Ashley S


Masterd


redone

There certainly needs to be a more streamline way of including custom code in your forum- that obviously effects themes for the most part.

For beginners the good thing about curve has been that ability to modify very easily. Simply put but not done is the separation of modifications from themes period. Not easy but very essential for future versions of SMF.

~RedOne

bloc

Quote from: RedOne on March 27, 2011, 07:50:00 AM
There certainly needs to be a more streamline way of including custom code in your forum- that obviously effects themes for the most part.

For beginners the good thing about curve has been that ability to modify very easily. Simply put but not done is the separation of modifications from themes period. Not easy but very essential for future versions of SMF.

~RedOne

This isn't new - I talked about this for over 4-5 years ago and nothing has happened since then. If anything its gotten worse, so I am done trying to change it.

The sad truth is that no-one cares about innovative and exciting themes - but they do care if their 50+ mods work or not. So why waste a whole system on themes which no-one utilizes anyway? The conclusion is to remove it and bet on variations instead.

Give me just ONE example of a theme that fully use the system today.(aside from my attempts) If you do find one, compare that to the 100+ other themes that DON'T. The math is quite simple here.

Arantor

To be fair, the majority of those who actually tried to push the boundaries of what could be done with themes disappeared a long time ago. The same is mostly true of mods, too, that people who really put in the time to come up with something different and new mostly left a long time ago.

Consequently, the only knowledge that's left is how to approach things from the simplest direction - for themes, we're talking simple variations; for mods that's the shortest route to achieving the result by template changes. So much more is possible without template changes, yet invariably it doesn't happen.


I actually have a few examples of this drawn from the work that's gone on with SimpleDesk, both historically and recently. It has a feature whereby you can turn off the forum stuff and just have a helpdesk, which is cool since you get a bunch of themes for it :) But that means removing the unread/unread replies links from the header, as well as the search box since we don't have a search function (yet). Now, I could have done that with template edits and driven myself mad(der), or I could be a little more creative and use the buffering system to allow me to edit it after the templates are done - without a template edit.

Another thing I've been playing with is the ability to present the helpdesk as a board, much like Project Tools can, except I was conscious of two problems: users with custom themes with a custom board index, and users who use things like the vB style board index mod, both of which prevent Project Tools from working to its best. But armed with the knowledge of SMF and a suggestion from SleePy, I crafted it to work without a theme edit, and still present it nicely - and however the theme would make use of that information.


What I'm getting at - slowly - is that the problem is not so much people wanting their mods to work (hell, I want all my mods to work too) but more about the fact that the mods themselves do not go into as much thoroughness and depth as would be best for them to do, and invariably the shortest route between two points is what's taken. I remember spending so much more time on mods to avoid making theme edits and I got a much lower support overhead as a result (then it just became a mess of people whining about things I didn't want to implement, but that's another story)

What it really needs is people generally to build mods better, to not require theme edits where possible, to make use of the full range of techniques to avoid theme edits so more and more mods work on more and more themes. It's possible to do all kinds of things with sufficient ingenuity, as I've proven more than once.

Antechinus

Why remove the ability to make truly custom themes though? If people don't use it very often is that a reason to stop anyone ever using it? Personally I'd like to think we could keep that flexibility.

Arantor

Because the rest of the SMF ecosystem actively forces themers NOT to be custom.

People want their mods to work and they'd rather sacrifice themes in the name of mod compatibility - in which case, might as well remove custom themes so that mods always work. It would certainly improve compatibility of mods and raise the profile of SMF as a whole that mod installs are more likely to work.

You'd still have jokers like me who go to extreme lengths to avoid theme edits, but people like me are the distinct exception. Can you imagine someone carving up Subs-BoardIndex.php to build fake boards (and even fake categories at times) and adding a call in the output buffer handler, instead of just tacking the new markup into the theme? Honestly, can you imagine that? Because I can't.

live627

But would ripping out the theme system truly solve the problem? Let's think about that for a minute.

A higher load would be on the support staff because people would constantly be asking (demanding) how to change the look of their site. And such an action would possibly cause a rebellion since people would be like "Oh SMF used to support themes but now it doesn't while everybody else does, bye-bye!" They would leave SMF and these events would pile on to each other like pancakes and would ensure nails for the coffin.

And once the theme got modified, mods get more or less compromised anyway, so what's the point?

I'd like to propose something different. Infest the theme with hooks. Place a big, bold alert on mod installs that modify the theme. Maybe even disable $themedir altogether.

Arantor

QuoteMaybe even disable $themedir altogether.

*shrug* Then you have to disable $themes_dir too ;) Oh, and it'll break mods that add images into the theme dir, or CSS files...

Yes, you can throw a boatload of hooks at it, it'll certainly help. It won't achieve everything though.

Norv

If the problem is that mods edits cannot be done in certain custom themes... then:
- you can switch (deeply changing) custom themes to mod packages. That doesn't remove themes..., it forces them in mod format. That allows a bit (arguably) better handling because at least it shows you when there are conflicts, it edits less code, too.
Yet, you'd still have the conflicts, because if you couldn't install a certain mod on a custom theme as it would be today, then if you package the theme as a mod, you'd still have that edit fail.
- you can have an API for theme insertions/changes. (i.e. hooks, events, etc). It will allow you to do things that change the layout (certain defined parts), and can be used both for a "theme" as for a "mod".
- you can have an API to add parts of your own...

Why do mods modify themes?
This is a serious question. :D
We have many mods in this community, testing the possibilities of what SMF can be made into. What are the things that mods need to modify themes in order to do them?
To-do lists are for deferral. The more things you write down the later they're done... until you have 100s of lists of things you don't do.

File a security report | Developers' Blog | Bug Tracker


Also known as Norv on D* | Norv N. on G+ | Norv on Github

Arantor

QuoteWhy do mods modify themes?

Invariably the answer isn't because they have to, it's because it's the shortest route for them to do so. I've demonstrated time and again that theme edits do not always need to be done, even for very complex operations.

Case in point: SimpleDesk removes links and facilities that appear in the default theme and in index.template.php and yet doesn't require a theme edit to achieve this. It also dynamically extends the board index to produce custom boards that are directly geared to it, and yet doesn't require a theme edit for that either.

In the past I've also added an MP3 player widget to attachments, a popup menu appearing on the usernames in posts - and all these without template edits.

I'm sure if I go back through the mods I've written I can find you more examples where functionality that traditionally would be done with theme edits can be added without, though it's through hoops. Adding hooks removes the need to jump through hoops so much, but a far bigger problem than the lack of hooks is the lack of people willing to spend time getting to understand SMF's internals to the point where they would be able to achieve things without theme edits.

I'm not a genius, far from it. But I am resourceful enough to examine the source and figure out how to avoid theme edits where possible, for the benefit of everyone else who uses my mods. But most modders are not that resourceful, and as such a theme edit becomes all is going to be done.

mashby

I guess there are two types of "mods" from my experiences. The first is more literal. It modifies or adds to existing functionality. ImagesOnBoard/CBI is a good example. Adds an image next to each category when viewing the board index. I know I'm leaving out a billion others... The other adds functionality. AEVA/Gallery/Media mods. And these almost always affect index.template.php to add a menu item in 1.1.x (not true in 2.0 though) and independent display/source files.

To me then, a theme should really just be affecting the entire look and feel of the site (index.template.php). If I ever install a theme that has more than index.template.php (other than the obvious CSS and images stuff), I always delete the extra display files like BoardIndex and others.
Always be a little kinder than necessary.
- James M. Barrie

bloc

Quote from: Antechinus on March 27, 2011, 06:17:44 PM
Why remove the ability to make truly custom themes though? If people don't use it very often is that a reason to stop anyone ever using it? Personally I'd like to think we could keep that flexibility.
"Not very often" is an understatement lol, you can count the themes that does it on one hand only, at least the free ones. Are the custom themes on peoples sites more "customized" than the free ones? Perhaps. But in both cases its a highly underused system and there have been done VERY LITTLE to resolve that. Yeah, the hooks are good..but thats just adding buttons to a theme. And theres certainly no documentation easy available that show just how modders can use the various hooks in source files..not one that i am aware of.

The problem is still there: mods modify themes out of convenience, lack of knowledge or something between. Theme authors dare not change it since they know many will need support on how to make xx mod work. They rather have the theme work right out the box, and who can blame them? Most of them are designers first, coders second. It discourages them to use the system fully, thus its a waste of resouces. Color variations are more than enough to accommodate theme needs then. I am sure that with minimal changes to Curve it can be even better to throw only CSS edits at.

Quote from: mashby on March 27, 2011, 11:24:05 PM
I guess there are two types of "mods" from my experiences. The first is more literal. It modifies or adds to existing functionality. ImagesOnBoard/CBI is a good example. Adds an image next to each category when viewing the board index. I know I'm leaving out a billion others... The other adds functionality. AEVA/Gallery/Media mods. And these almost always affect index.template.php to add a menu item in 1.1.x (not true in 2.0 though) and independent display/source files.

To me then, a theme should really just be affecting the entire look and feel of the site (index.template.php). If I ever install a theme that has more than index.template.php (other than the obvious CSS and images stuff), I always delete the extra display files like BoardIndex and others.

Which proves my point exactly. SMF users can't be expected to be visionary and see what a full-on theme system can do, that has to come from the team -> meaning MORE must be done to solve this problem. But if the team doesn't see it as a problem, then the only logical conclusion is to simplify it and remove the full-theme feature altogheter.

Lets look into the future. Right now I know that at least mysefl dabbles in making changes in more than index.template. When I stop doing that there will be nonw(that I am aware of at least) and people will continue on the current trend: css and index.template, nothing more. In SMF 2.x more edits will prob. make into Curve theme to make it better, perhaps even a new theme will be added. I do foresee a new theme BASED on current markup though, just because so many themes/mods now rely on Curve anno v2.0.

So who will use this wonderful system then?


live627

Yeah, the problem with the hooks is they're relatively obscure and unknown. However, there is a document in the wiki here attempting to change that...

A hook can be added anywhere, not just expanding the buttons like now. One can be used in Settings to extend the theme settings; in Display between each post for HTML ads and blocks; on BoardIndex to change the list; GenericControls to add to the post buttons; I could go on to cover each template. But the point is: hooks can extend anything from the moon to the kitchen sink.

Arantor

QuoteYeah, the problem with the hooks is they're relatively obscure and unknown. However, there is a document in the wiki here attempting to change that...

And it's a virtually direct copy of my guide for RC3, which means it's missing some hooks and is likely incorrect in other ways too.

live627


Norv

A point that I need to make here is:
The "shortest route" is not a bad thing, here, it's most of the time a correct way to do it. Mods should not be forced to take a "longer route" (and sometimes disputable) in order to make visual modifications that have less maintenance issues. Modders should not have to read all SMF code in order to know how to do a simple thing with less maintenance issues. If it is really necessary for them to take too long or disputable workarounds in order to achieve that, then that is bad design of the software itself.
Modders should not need to deeply modify core in order to do visual changes in a way that is less conflict-prone, less error-prone, with less maintenance issues than they have today.

On the contrary, if making visual modifications is prone to maintenance problems, and/or affects themes creativity, SMF should provide easier ways to do them, in a way more viable in the long run.

That said, may I go back to the details :)

Adding more hooks, that mods can use to modify/insert bits of data or implement behavior, without directly modifying the core, will help. We know that. That's on a rather short-medium term though, i.e. 2.1, and it will likely bring an improvement, it won't be exactly a silver bullet.

You know... It's amazing in a way, to see how popular hooks have become, since RC4 added a little API for their easy use (along with a few more for heavily modded areas). Sure it can be much better, but it's still amazing, because hooks were always there, they weren't many, yes, but they are not many today either. They're not properly documented yet. They're not made known properly yet. The API is really basic for now. And still, after this little API was added, along with a few hooks additions, we have suddenly received much more interest about them than one would expect from a (currently) under-documented feature, questions, requests to add others, from everyone, community, modders, team.
We knew it was the right thing to do, but it's still amazing how it turned out. ;)
An easy to use and understandable API to do things - and it can be much better -, without needing to edit themes (and not only themes), means exactly: a way to do things that doesn't require to heavily delve into SMF innards, on the contrary, and still have little issues on the long run.

Don't think it's a silver bullet though. It's not. It's just a little step in the right direction. There are more to make.
A last note on this: please feel free to propose hooks for needed areas (for 2.1), help with the documentation (thank you,  Arantor and live!), examples of use, point out whatever you feel it's lacking. It took off unexpectedly well under the circumstances, but there are a lot of things left to do there, and we need your feedback and help.
To-do lists are for deferral. The more things you write down the later they're done... until you have 100s of lists of things you don't do.

File a security report | Developers' Blog | Bug Tracker


Also known as Norv on D* | Norv N. on G+ | Norv on Github

Arantor

QuoteThe "shortest route" is not a bad thing, here, it's most of the time a correct way to do it. Mods should not be forced to take a "longer route" (and sometimes disputable) in order to make visual modifications that have less maintenance issues.

So, a route that quickly causes conflicts is the 'correct' way to do it? Really? Thank $deity then that I'm stupid enough not to use the 'correct' way.

QuoteIf it is really necessary for them to take too long or disputable workarounds in order to achieve that, then that is bad design of the software itself.

Then SMF is badly designed. Any theme that wants to be creative has to do so at the peril of making mods more fragile, which was the point of this thread, and is why most themes just don't bother being creative. Mind you, most mods conflict with one another because of the same problem...

QuoteOn the contrary, if making visual modifications is prone to maintenance problems, and/or affects themes creativity, SMF should provide easier ways to do them, in a way more viable in the long run.

Yes, it should. In case you missed it, this thread was about forcing SMF to stop sitting on the fence and pretending there isn't a problem with the status quo, because there is.

QuoteSure it can be much better, but it's still amazing, because hooks were always there, they weren't many, yes, but they are not many today either

Apart from the fact that they were fundamentally broken, unusably so, prior to RC4 because you could only ever call one function per hook at that point, and there weren't very many hooks that were actually useful outside of integrating SMF to something else. These things changed, which is good.

Mind you, I stand by my assertion that the current changes are half the job, either they should have been left alone (in line with the feature lock) or done thoroughly, not scattering maybe a dozen new hooks about the place. There are reasons why other systems have hundreds or thousands of hooks... not a couple of dozen.

QuoteA last note on this: please feel free to propose hooks for needed areas (for 2.1)

Just ask SlammedDime, that's a good enough head start. Though how about every single action, every single template, breaking some of the stuff down into more modular units, then having hooks for those too.

Oh, and the ability to actually require a file elsewhere other than just on the main page load, I don't want to add a trillion files every page load if I don't need them, thanks.

bloc

You know...if SMF really wanted to finally let mods-changing-templates and themes-changing templates co-exist in harmony, you would pick up ideas that were brought up ages ago: that of compiling templates.

Hooks are nice, but they are too few and too late IMO. The theme-base won't change now, not now that so many mods will prob. not even convert to it. It should be done years ago.


But maybe this is really futile anyhow... do people really WANT other themes than the old trusty "standard forum" layout? Ask Mashby here, or any of the others that agreed on my proposal in this topic and you will know the answer is a resounding "no".

All the more reason to stop pretending SMF is such a great theme-encouraging software when no-one use it anyway. So clean out house and bet on variations - simpler and cleaner and no doubt following the tradition so far anyway.

Norv

Yes, we should look at compiled templates, too, BlocMan. Though not for 2.x line. If you have suggestions or examples, please do tell.

I'm not sure there is much I can do about the fact that hooks changes should have come sooner. :)

As it stands, hooks as they've become today are an easy enough way SMF can offer modders now, for widely modded areas of SMF (where hooks exist). They allow customizing without risking edit failures, meaning support issues, whether because of custom theme code or other mod code. That will be true for 2.0, and we are looking at increasing the extension points for 2.1, along with templates and core code cleaning. Sure, we should also make them known better, along with documentation and example usage, but that will come.
Now, a way exists, and that is what 2.0 has. It is up to the modding community to take it up, if they find it useful and easy enough.

Arantor,
Yes, SMF code and architecture has its bad parts, as well as its good parts. The reasons why it seems to require heavy workarounds to make simple visual changes with less maintenance issues in the long run, are among those that should be improved.
There is a lot to discuss here, please allow me to mention again one simple possible route: analyze the mods' needs, and establish a list, as complete as possible, of what mods need to change in templates, specially what they need more often. Some are obvious, or often needed, like mashby's example, add an image or text to an existing element on the page. Others, less so. That's why we ask the modding community to let us know their needs, their requests, their suggestions for future hooks.
We can look then at improving, or, as needed, refactoring SMF, such that mods can use additional hooks, or an API, to make those changes.
If it helps modding with less maintenance issues, it can be done, and it's one of the few refactorings that can probably be made for 2.x. (where 2.x > 2.0)
To-do lists are for deferral. The more things you write down the later they're done... until you have 100s of lists of things you don't do.

File a security report | Developers' Blog | Bug Tracker


Also known as Norv on D* | Norv N. on G+ | Norv on Github

RustyBarnacle

I'm a heavy theme user myself.  Almost all of the forums I've built over the years have had Bloc's themes, free and paid, because they are unique.  I don't really want my forums to look like everyone else's.

I also use a lot of mods.  Some work out of the box, some I need to tinker with, some I need to really think to figure out, but I usually get there eventually.  I know I'm in the minority, just showing appreciation.

vbgamer45

I would like to see a new section called skins/variations. Which are just .css and image replacement changes that overwrite the default theme. I do this on my free hosting sites to allow users to customize their boards.
Community Suite for SMF - Take your forum to the next level built for SMF, Gallery,Store,Classifieds,Downloads,more!

SMFHacks.com -  Paid Modifications for SMF

Mods:
EzPortal - Portal System for SMF
SMF Gallery Pro
SMF Store SMF Classifieds Ad Seller Pro

redone

Either way you slice it modifications should not require theme edits. The good news is that with future versions of SMF you have the opportunity to start from a blank page.

The package manager back in the day is what brought me to use SMF rather than other boards. I still think that feature alone is a huge reason people use SMF today.

I have used Drupal to a great degree over the last year, and yeah I will here well thats a CMS and thats different. But the object of the exercise is the same - to modify a base install. You should be able to install any theme you like without issue.  Future versions of SMF give everyone the opportunity to offer customization above and beyond what has been done before.

~RedOne

Antechinus

Quote from: MSNNorv says:
we need a theme for smcore
we're setting up smcore.org, with a forum
Antechinus says:
ok well people want to ditch themes
so just echo the basic html
that'll f**k 'em


Arantor

Easier mod installs and every forum looking basically the same, just with different colours. Good plan, there.


Norv

Quote from: RedOne on March 30, 2011, 05:08:37 PM
I have used Drupal to a great degree over the last year, and yeah I will here well thats a CMS and thats different. But the object of the exercise is the same - to modify a base install. You should be able to install any theme you like without issue.  Future versions of SMF give everyone the opportunity to offer customization above and beyond what has been done before.

~RedOne

As you say, Red One. :) However, I'd mention that actually, there is/was a difference in the exercise... if I may nitpick the term you used.
SMF up to today (RC4/RC5) has mostly treated customization as modifying the base install, in its literal sense, in almost anything. (with few exceptions like the subscriptions component). That's not the same actually, with extending the base install, overriding and changing behavior or looks, whether by hooking into it, by using an API, and not only.
To-do lists are for deferral. The more things you write down the later they're done... until you have 100s of lists of things you don't do.

File a security report | Developers' Blog | Bug Tracker


Also known as Norv on D* | Norv N. on G+ | Norv on Github

Angelina Belle

Never attribute to malice that which is adequately explained by stupidity. -- Hanlon's Razor

Antechinus


bloc

Quote from: AngelinaBelle on April 10, 2011, 03:08:57 PM
A lot can be accomplished with CSS, if the HTML is designed with that in mind.
http://www.mezzoblue.com/zengarden/alldesigns/
I have known CSS Zengarden for years, and its very inspiring. But there are several things that make using that model difficult in SMF:

- all list items in Zen are a set number, the same in every design. SMF is dynamic, thus any pixel-perfect area can't be made from CSS as easily.
- Zen has several markup placeholders that do nothing than act as hooks for the CSS elements. SMF markup was written to use as less markup as possible.
- Zen has one single layout, SMF has arguably 15-20, all of which are dynamic in nature. Mods also add columns and whole sections that can't be  predicted by the CSS.
- The creators of Zen knew EXACTLY what went into the markup, in SMF you will not. That made optimisations easy for Zen, while hard for SMF.

So yes, its inspiring, but its not immediately transferable. In a way SMF 2 already did in part what you suggest: it has markup that should only have to be changed by the CSS. For example the headers or the framing CSS, these can be changed only by CSS to new innovative designs(with perhaps a few more placeholders). Trouble is that the Curve CSS is really made for ONE specific design in mind, that of the round layout of Curve. Time has shown that very few actually harness the CSS power to tweak it at all.

So what would make you think those same users would handle JUST the CSS to create such inspiring designs as Zengarden spawned? IMO: nothing. My suggestion in this topic is purely to remove something which isn't used anyway - not because its "worse".

Angelina Belle

You make a good point.
It is easy for me to move <div class=middletext, but not easy to move
<div id=topsection (it just doesn't behave well when I try to position:fix it at the bottom of the page)

I think that, if it were easier, I'd fiddle with that to get things where I'd like to see them.

But I decided, after a couple of hours of playing one day, that I lacked several skills required to produce anything like Manuscript. Except, you know, with a nautical theme/framing images, a racing trophy and coffee-stained bylaws and a club snapshot...

Producing a nice theme simply not very easy. That's one reason "nobody" does it.
Never attribute to malice that which is adequately explained by stupidity. -- Hanlon's Razor

bloc

Yup. :) I've spent countless hours testing various variations on CSS Zengarden, because i *really* like the aspect of that. But in the end its an impossible task, simply because so much must be rewritten...

But nonetheless I am once again striving for a solution lmao, although its not so much Zengarden(change only CSS for new designs) as "change every HTML in every theme" type. So a different direction, unfortunelately.

I know a member once did a Zengarden theme for SMF, in that he took the designs from Zengarden and wrapped them around SMF subtemplates(that is, the boardindex, messageindex etc) so index.template was essentially a wrapper for Zengarden. But I am not sure how far he got on it.

Yes, its hard to create good themes, and even harder to produce something new and exciting in terms of layout and style. Yes, its possible to create nice variations of the Curve theme - but making Curve itself took me a few weeks trying new ideas and not stray too long from the "normal" forum(although thats what I most often LIKE to do lmao) . That was over 2-3 years ago. The team perfected the HTML/CSS for Curve, so now its easy to make those variations - but its colour-book style themeing IMHO.

Angelina Belle

SOME items generally contain the "expected" stuff, and so USUALLY could be made CSS-movable, because they would behave well, if they were set up to do that.
Like the button menu, the user information, etc, the top banner.
Never attribute to malice that which is adequately explained by stupidity. -- Hanlon's Razor

Antechinus

Quote from: AngelinaBelle on April 11, 2011, 01:30:25 PMExcept, you know, with a nautical theme/framing images, a racing trophy and coffee-stained bylaws and a club snapshot...

Producing a nice theme simply not very easy. That's one reason "nobody" does it.
Sounds like fun. Give me a yell if you want to try it again and get stuck with anything. :)

Angelina Belle

The first difficult step is obtaining good graphics. If I can manage that, I might just take you up on your kind offer.

Thanks!
Never attribute to malice that which is adequately explained by stupidity. -- Hanlon's Razor

Antechinus

Found this the other day. Very handy source of various images, although I haven't looked for nautical stuff yet. http://www.photos8.com/

Angelina Belle

(ot) but thanks. I'd need good images of club-specific items, which I don't have yet. Only lousy ones.

On the other hand, here is an example of a themer chomping at the bit.
Or else -- maybe, with a "one size fits all" theme, it would only be necessary to drag in new images and adjust the CSS a little bit.
Never attribute to malice that which is adequately explained by stupidity. -- Hanlon's Razor

Advertisement: