I’ve been trying to stop myself but I can’t:
What you are describing seems to be a traditional RW Theme. Header, Footer, Menu and some per page stacks content.
Food for thought.
1 Like
Never thought about it like that. But yes, interesting indeed.
I’ll make you a custom theme for each of your sites for only 2 grand a pop :)
3 Likes
That is an interesting issue.
What would your dream tool do to solve this?
Obviously preview is great.
And the idea of working on a smaller component it great.
But how do you preview this small chunk? It would be free of the Framework’s base-CSS – and any other page-level goodies you’ve added.
Would you:
- preview it without the base CSS? Fast – but potentially not very WYSIWYG.
- preview it with the base CSS? Not as slow as previewing the whole page, but the base CSS stack is often the slowest bit for the exact reason that it provides all the CSS.
- preview – but with some special set of CSS?
- preview it with the a specific page – probably the most WYSIWYG – but also very slow
- preview it with the page it will eventually be used on. exactly WYSIWYG – but likely so slow that it’s not even worth making a partial
Or maybe something else?
You dream it – I’ll try to build it (some limitations may apply to this deal, so us my desire to have a life and see sunshine every couple years)
Isaiah
2 Likes
There’s a push and pull here that’s very interesting.
There has always been a huge customer desire to be able to build/customize/modify themes via drag-and-drop tools.
I would happily provide these tools via Stacks or some other plugin if there were a way – but the API into the RW theming system is limited and mostly private.
But – and i’m totally guessing here – I suspect these limitations (both to the API and that the app hasn’t built the features either) aren’t just omissions, but at least somewhat purposeful limitations.
Why?
I think the reason is simple: the rapidweaver guys know that design is much harder than most people think.
- Give novices the ability to build a bunch of content – fine. Everyone is the expert of their own content after all.
- Give novices the ability to design their own website – aaaaghhhh! Shield your eyes, oh the humanity!
So rapidweaver places a large enough barrier around theme designing to discourage casual users but not so hard as to discourage designers. Or, well, that’s my guess at least.
I’m not going to dig in to how I think this could be improved – but suffice it to say I both get why things are the way they are – and see a lot of room for innovation.
While I think giving users pre-made designs is great – it seems like a bit more freedom to tinker would be welcome without causing too much carnage. And maybe giving consultants a way to quickly build a theme in a code free – or maybe code-light way.
Until someon builds that tool, however – we have some pretty good frameowrks from a variety of stack developers.
And previewing partials remains a practical challenge. :-)
Either I’m over simplifying it or your over-complicating it…
Bring back preview of partials in edit mode?
I realise this is far easier to say than do, but I can’t think of a better way to put it. Previously, being able to preview partials as you edited them worked perfectly. Maybe there is an even better way to do it, but I can’t say I ever felt anything was lacking previous to S4 in this regard.
I agree and I would not change this. The thrust of this thread was however a way to have custom content for “most” of the page but to have a standardised menu, header and footer. I may be generalising but I think that the first two of these tend to be the things that people struggle with designing/implementing when using blank page frameworks.
Most users are not designers let alone UI engineers and so providing these crucial areas of the page ready built could be a real help. Suppliers of “template” projects for frameworks seem to be still doing well, perhaps in part because people need a starting point to “modify” rather than “designing” from scratch.
I’ve made several custom themes for people to use with Foundation stacks in the past for these very reasons. Given that some project files sell for $20-30 and most menu stacks seem to be $30-50 I would have thought that there would be a reasonable margin for someone wanting to go down the third way.
Great as frameworks have been for stacks, bearing in mind that BWD’s sole existence happened to encourage their use and dissuade people from the view that “all Foundation pages look the same”, they have undoubtedly caused the near death of the theme market. Perhaps there is room for a cooperative resurgence.
1 Like
Excellent food for thought. I have often seen RW stacks sites created with Foundation or Foundry that look like they were created using a theme. They followed a simple Nav, top section, mid section and footer throughout the site. Definitely in the Bootstrap theme market there are repeating designs that are easy to identify and would make excellent themes.
A while ago, I did investigate the RW theme documentation with a view to seeing what was involved in making a theme and frankly gave up through lack of inspiration when I saw what little was possible.
Probably too late now, but the theme API never seemed to get developed to where RW could have used it’s best asset.
Absolutely. Even artists would struggle with a blank page looking at a blank white wall - apart from Maurizio Cattelan and Banksy.
This was one of the main aims of my Templates and Projects to get users going with set of pages that they could start with a complete non blank page, and then cherry pick from different pages to cut and paste, delete stuff from and modify the content of the building blocks.
However, those who can figure it out, can now use Stacks4 Templates and Externals for Navigation, Footers, etc… Externals is perfect for this. As omg as users don’t go mad and convert everything into Externals, then it shouldn’t be too difficult to manage.
Stuart (STH) was very early in adopting adding Templates to his Source stacks and when more developers use this powerful Stacks feature, it will help to lessen the pain of the blank page syndrome.
Not disagreeing but I would just return to the original point of the post. Steve wanted to break up pages because of the number of stacks / complexity / performance. This is the only reason that I mentioned the theme approach for common elements.
1 Like
…are exactly why I was waiting for Stacks 4 before releasing MenuLab. I have 20+ mini menu components all sharing common code that could all be built into pre-made templates in varying combinations.
1 Like
The theme discussion is really interesting, as is externals. I’m not 100% sure externals is the way to go, as you are filling up people’s externals folder, and adding to the overall weight of RW, by adding externals to projects.
I think a better approach is to educate the user about externals, then give them thr option to create their own from pre-built stacks elements.
Going back to my original question…
As @isaiah pointed out, S4 has almost solved the issue I face by making it possible to edit the partial from thr partials folder. It just needs the new preview handicap worked around.
Once that is solved, I can see a whole new, faster, way to build pages in RW which for me would xhange my work flow entirely.
Well I think we would all have like to check out those Templates!
Templates are so under appreciated IMHO.
I do however see future demands for a Template / Externals manager, because as more and more developers use the stacks template delivery method, I predict that the Template libraries are going to fill up quickly to a difficult to mange size.
I would also like to see a Don’t Add the stacks Templates option, for stacks that I am familiar with.
I like the approach that BootstrapStudio uses for the downloaded and built-in building blocks which are equivalent in many ways to Externals / Templates.
…what might have been… oh well.
Wordpress?
-
Can you explain a bit more. Not sure I follow.
-
Since you are a developer, can I ask that you just add this to the bug/feature tracker? Otherwise these sorts of things just get lost in a sea of old forum posts. Feedback from developers is golden – I need to capture that so it can become some future 5-little-things video of some future release. :-)
You seem to have conveniently ignored much of the rest of this question. LOL.
All of the options I posted above “bring back preview” – the problem is that previewing just the content of the partial – without the rest of the page – is just not especially useful.
For example: Try taking just the contents of a partial and drop them into a blank page and click preview.
If you’re using most frameworks, like Foundation or Foundry, you see: Warning please use this with the ##base stack name## on the page.
Some stacks partially avoid this by putting some basic CSS inside EVERY columns stack. This, of course, really slows things down (yuck) – but even slow – all of your carefully chosen styles, fonts, spacing, etc – all gone. You’re left with an anemic white page and your partial content.
Is that really what you want?
I mean, I can give you that option – but I’m guessing you have something else in mind – but I’m not exactly sure what that is.
Yes I will add it after some more thought. I’m still trying to fully appreciate how this will pan out.
Yes, I was indeed over simplifying it!
OK, so how about this…
When you create a Partial you have the option to tick a box… “Load this Partial when editing other Partials?”. I can now tick this box when creating Partials of the style stacks, font stack etc. Then, when I preview another Partial these load behind the scene and everything looks as it should.
I don’t want these Partials to load into edit mode though, as they can slow edit mode down. For instance, if I put my navigation system in a Partial, I might like to have it display when previewing other Partials but I don’t need it in edit mode, as it’s just adding bulk to the edit page, so slowing it down.
Doable?