search

OrchardCMS / Orchard

Orchard is a free, open source, community-focused Content Management System built on the ASP.NET MVC platform.
https://orchardproject.net
BSD 3-Clause "New" or "Revised" License
2.37k stars 1.12k forks source link

New out-of-box default theme #6391

Open DaRosenberg opened 8 years ago

DaRosenberg commented 8 years ago

As discussed in weekly meeting 2016-02-09, I'd like to try and drive the efforts towards a new default theme for Orchard. I thought the first step should be laying down a set of design goals and requirements, so I've been doing some background thinking this weekend and here is a summary of what I'd like to accomplish.

Design Goals

Visually appealing yet customizable/extensible

Whereas TheThemeMachine heavily favors customizability and extensibility over visual appeal, the new theme should strive to serve both these needs. The markup should be very clean and semantic (not littered with presentational classes) while the stylesheets should render that markup in a visually appealing way.

We should consider the following scenarios of customization:

By carefully considering how stylesheets are structured, by basing the theme on a known framework such as Bootstrap, and by utilizing preprocessor variables, I think we can both be beautiful and make life a breeze for theme authors when using the new theme as a base.

Generic yet unmistakably Orchard

I have approached @ryandrewburnett to help with the visual design, and he has responded enthusiastically.

The theme should look generic enough to appeal to a wide audience and work well for most simple web sites, but it should also have a few key elements which make it look "unmistakably Orchard". There is a balance to be stricken here, but I think a good starting point would be to use a few Orchard visuals (such as the logo and icons) along with using the traditional Orchard green as an accent color.

In any case, all of these things should be configurable. The theme should look slightly Orchard out of the box, but site owners should be able to easily change out these logos, visuals and colors from the admin UI.

Heavier or layouts, lighter on global zones

TheThemeMachine was constructed for a world without layouts. Layouts were sort of bolted on as an afterthought. The new theme, by contrast, should fully embrace layouts and elements, which means going easier on global zones and widgets.

This does not mean the new theme should have no global zones - it just means it doesn't need nearly as many of them as TheThemeMachine. Having some global zones is still very much necessary to place navigation widgets, to emit INotifier messages to the front-end, and so on.

In the new theme these global zones should be primarily vertically oriented (positioned above and below the Content zone) leaving the Content zone to span the full width of the page to enable greater control by site editors of page layout. It's probably important for most editors these days to be able to use modern design constructs right from the layout editor, such as "stage" visuals and full-width page sections with alternating background visuals.

Responsive

Needless to say, the new theme should be fully responsive.

Scope

TheThemeMachine still remains

First of all, TheThemeMachine should not be removed. It should still be considered the "core" theme of Orchard from a module development perspective. Today TheThemeMachine is really not contained in the theme only - it is actually spread out across all modules in the code base. Most core modules today containing core templates for their shapes do so assuming TheThemeMachine as the target. This means the theme itself contains very few templates. This should continue to be the case, i.e. we will not be touching the shape templates in modules.

Instead the new theme will contain overrides of all these shape templates, which means the new theme will contain a lot of shape templates. This should be considered a good thing, as it will also make customization much easier. Custom theme authors will no longer have to search the whole codebase to find the original shape template to override, instead they can base their theming effort on what they see right in front of them in the new theme, systematically going through all the shape templates and make sure they adhere to their customization needs.

Covers all non-deprecated functionality

The new theme should contain shape templates and styling for all non-deprecated functionality in Orchard, not just the features enabled by default. For example, if you enable Orchard.Search on your site, it should already just work and look good.

Also comes with new out-of-box recipes

As part of this effort we need to refresh the out-of-box recipes also, for multiple reasons:

  1. They should enable the new theme instead of TheThemeMachine.
  2. They should create content that is more taylored to the new theme.
  3. The current ones are generally outdated and use commands for things that should now be done using proper recipe steps.

We might keep the old recipes but deprecate them.

Includes overhaul of setup page to match

To create a smooth and coherent out-of-box experience for Orchard, as part of this effort we should also update the look and feel of the setup page to match the visual design of the new theme.

Functional Requirements

Skinnable

As mentioned above, the new theme should have a default appearance that is generic yet unmistakably Orchard. However it should also be sufficiently configurable from the admin UI to allow site owners to differentiate their sites visually, and change these "Orchardy" defaults to something that's more unique to them.

There are many potential ways to do this, but I believe a good starting point would be:

We might potentially utilize the work done by @sfmskywalker on a framework for theme settings.

RTL support

The new theme should fully support right-to-left cultures.

Technical Requirements

Based on Bootstrap 3/4

The general consensus in the community seems to be that the new theme should be based on Bootstrap. There are two main reasons for this:

  1. Not re-inventing too many wheels
  2. Making it easy to extend/customize the theme

In particular no. 2 means anyone who is familiar with Bootstrap markup and stylesheet structure will find it immediately familiar and easy to adapt the theme to their needs. Theme authors don't have to spend a lot of time learning and understanding the theme; instead they can just employ the knowledge and experience they already have because the theme is structured in a very predictably Bootstrap kind of way.

Bootstrap 4 is currently in alpha 3, and it's reasonable to expect it will reach RTM this year. We may consider going straight to Bootstrap 4 for the new theme. There are many benefits over Bootstrap 3 - flexbox support stands out as a personal favorite. This would also require adding support for SASS to the Gulp pre-processing pipelines, which is something we have already wanted to do.

Built for modern browsers

The new theme should not compromise cleanness for compat. The general workflow should be to implement according to web standards/specs, develop/test on a modern browser of choice, and finally do a round of wider browser testing close to release to ensure compat across the gamut of modern, standards-compliant browsers.

In particular, IE10 now has a market share of 0.6 % globally, and we should consider it an unsupported browser for the new theme. This allows us to rely on flexbox support among other things to keep the quality high and the implementation clean.

For the few people out there who feel they need compat with older browsers, we can refer them to TheThemeMachine which is still kept around.

Uses Gulp preprocessing pipeline for everything

The new theme should fully utilize the Gulp preprocessing pipeline, both for its own resources but also for its dependencies such as Bootstrap. By integrating with Bootstrap on the LESS/SASS layer, the new theme can override styling of Bootstrap constructs by overriding LESS/SASS variables and overriding/augmenting Bootstrap mixins. This dramatically reduces the amount of actual output CSS needed.

For example, instead of the browser having to load both bootstrap.min.css and theme.min.css where the latter is largely an override of things in the former, the Gulp pipeline can render one bootstrap.min.css from the Bootstrap LESS/SASS files combined with variable/mixin overrides provided by the theme.

In line with the principles already employed for client-side resources in Orchard, internal and dependency resources alike should go through the same preprocessing pipeline including transformation, minification and bundling.

No compat with TheThemeMachine

The new theme should not strive to acheive any kind of markup compat with TheThemeMachine; there is no reasonable use case for this. There are likely very few sites that use TheThemeMachine for production use, most site owners will have built a custom theme or used another. Folks who have built custom modules that target TheThemeMachine can optionally update them to be compatible with the new theme instead, but they don't have to. As mentioned above, the cases where people are actually using these modules' default TheThemeMachine-based rendering for production use are probably very few anyway.

Feedback

Do you agree with these goals and requirements? Do you disagree with anything in particular? Is there something I haven't covered that you think should be called out? Please voice your opinions in the comments, and I'll regularly update this text as the discussion unfolds and a sense of agreement emerges on specific points.

I'll give this a few weeks to bake and mature before moving on to implementation.

DaRosenberg commented 8 years ago

Summoning @bleroy @BenedekFarkas @Piedone @sfmskywalker @sebastienros @ryandrewburnett @pszmyd - your input is needed on this. Anyone else's input is also highly welcomed!

rbnett commented 8 years ago

I agree with everything that you have said here. I thought I’d just pitch in and hopefully contribute something towards this…

I’ve been working on a theme called Bindery – I would appreciate it if you can go and take a look at how I have constructed the theme to see if you agree. Here’s a few things that I’d like to emphasise are going to change:

I have two more themes coming soon that are more business orientated and constructed in the same manner. If any of these designs are of any use – take them. All of the design belongs to me so you can take what you like, you can even use the entire theme if you wish.

My stance on Bootstrap is to consume what you need and nothing you don’t, which is how Bindery is constructed. I’m not a huge fan of including modals, tabs, accordions and every imaginable navigation configuration possible in a theme. Maybe I’m wrong however and including just what you need is backwards, but could this be a consideration for the new theme?

One idea that I’d like to share with regards to configuring the visual appearance of themes is site logos. I feel that this isn’t something that should belong to the theme, since the logo of a site doesn’t necessarily change with the theme. I also believe that this option should encompass favicons and mobile icons. With my themes I was going to build a module which adds settings to the site in order to add branding assets. These settings would then be consumed by themes which support the module. Users could then set branding assets and have them appear across any theme they choose. The settings was to compromise of:

Would this be something to consider as a core feature?

I think this is everything that I can think of for now. Aside from conveying Orchard's visual identity, are there any requirements in terms of the visual design or is this completely open?

rbnett commented 8 years ago

I created this last year (I think) as an experiment. I was wondering what everybody thought of it. Might be useful when creating a theme.

Orchard branding

Piedone commented 8 years ago

I'll read the original post thoroughly once I'm retired and have more time ;-).

I didn't catch anything that I'd be particularly disagree with.

Not sure how having fewer zones is something that would be an improvement, despite Layouts. Having a variety of zones like in TheThemeMachine (and I'd add, for similar-purpose zones keep using the same zone names - like Navigation, Footer - that became kind of a de facto standard) keeps options open without drawbacks if you don't use them all. And especially since we're talking about a theme here that most possibly would also be widely used as a base them, keeping options open is an important aspect.

To add to the previous: I'd also design the theme as a base theme, i.e. a theme that can be widely used for theme developers to build on (as this wouldn't compromise but logically extend the above listed design goals): code-level configurations building on existing ones in Bootstrap, fine-grained ability for overrides, a variety of element CSS classes and IDs, etc. allow these. For an inspiration take a look at Pretty Good Bootstrap Base Theme which was specifically built as a base theme (but in contrast without caring about the OOTB aesthetics).

sfmskywalker commented 8 years ago

I completely agree with Daniel's outlined goals and requirements. I especially like the modern, clean and attractive design based on Bootstrap 4 (not 3) and that it is more heavy on layouts, or at least less heavy on zones. It would be simple for theme developers to add new zones if they wanted to due to the Bootstrap factor.

I am really fond of having a configurable theme framework baked into Orchard, similar to what Wordpress and Shopify have, where theme developers can simply provide a theme settings schema, and all users need to do is provide values for those settings. This potentially unlocks a whole new set of new themes that allow the user to customize them, without theme developers having to code settings themselves, unifying the way theme settings work.

Regarding design, I love Ryan's design style, very happy he is onboard with this.

DaRosenberg commented 8 years ago

@ryandrewburnett Thanks for the input, and for being willing to help - your design skills will be crucial. I'll take a look at the theme you linked to.

I agree with your stance on Bootstrap - we should use what we need, but not compulsively try to cram every gadget in their arsenal into the Orchard shape templates. However, it would probably be helpful to themers if the customizations/overrides we make on the Bootstrap level in terms of visuals also work across the whole Bootstrap framework so that people are free to apply Bootstrap constructs even if we don't use them in Orchard.

I also agree with your thought on making branding assets configurable through a module rather than by a theme. I think a reasonable approach would be to add a few key such assets to the general site settings (along with the existing site name, culture etc). As you say, it would then be a responsibility of themes to render these where necessary.

Love the logo, colors and typography - definitely something we could base the aesthetics on!

DaRosenberg commented 8 years ago

@Piedone Thanks for pitching in!

You are right, there isn't necessarily any conflict between embracing layouts and providing lots of global zones, except in one way: the layout is one rectangular region, and we currently cannot mix zones into it. There's a hard boundary between layouts whose elements live within that region, and widgets which live outside of it. So if we want editors to have the full width of the page at their disposal when creating layouts (which I'm reasonably sure we want) we unfortunately can't also have widget zones in the same horizontal section of the page.

So, we could have the same abundance of global zones as in TheThemeMachine, but they would all need to be positioned above/below the content zone if we want people to really be able to utilize the full potential of layouts.

I have struggled with this in a couple of theming projects, and it's proven a very tough nut to crack. For example, it might sound simple to create a page layout that has aside zones to the right/left of the content zone. But as soon as you place anything in one of those zones, a whole column to the left/right of your content turns into empty wasted real estate, and that's rarely what you want. You can start messing around with floats to try and improve that, but that really only works reliably if your content is basically only a flowing text - not so much if it's a grid-based layout, itself heavily reliant on floats... yada yada, you get the picture. It gets real hairy real fast. ;)

As an aside, this is why we suggested a while back adding the ability to designate column elements as zones. This would allow for exactly that kind of "positional blending" of layouts with widgets that's impossible today.

PS. Oh and thanks for the obligatory "OMG wall of text, who has time to read, we are programmers here man" jab. Those are always encouraging... ;)

DaRosenberg commented 8 years ago

@sfmskywalker Thanks! Do you think it would be worth revisiting your work on configurable theme settings for this, as a general feature addition to Orchard? I always believed in the idea, not sure why it was never incorporated?

sfmskywalker commented 8 years ago

@DanielStolt Absolutely, it was designed to be a general feature addition to Orchard from the start. I believe the general consensus was that if themes need settings, those settings could be provided from the theme itself using C# code. Which is true of course, but I think it's a repetitive task enough to justify this be a core feature of Orchard. This also means a more streamlined story when multiple themes are installed and enabled, without cluttering the admin menu. Accessing theme settings is done via the Themes screen, where a "Settings" button appears next to the current theme. Also, theme settings are stored in profiles, which means you could have different sets of settings for a theme.

donaldboulton commented 8 years ago

Only Zones: Header, Navigation, Messages, Content and Footer. Use Layouts it gives us the versatility for all the other areas and zones. Maybe some hidden zones for comments, contact, and even login and registration. I hide my forms and open them in a Colorbox window = less clutter and helps on spam as the forms are initially hidden. Add a Elements folder with Element alternatives. No Styles, Assets, or Scripts folders are needed use Orchard.Resources.

sebastienros commented 8 years ago

So far I think nobody disagreed with everything you said, just details/confirmations. Keep it up! And thank you @ryandrewburnett for you support.

DaRosenberg commented 8 years ago

@sebastienros

geertdoornbos commented 8 years ago

For me, the proposals from @DanielStolt are a logical step forward and very welcome indeed. But, here is some feedback you asked for Daniel.

I think an Orchard Theme has always been focused on transforming content for the web, delivering html/css/js, to the browser. In that scope, there is a lot going on, related to web technologies. That scope is huge and growing and we're constantly trying to adapt to the situation. HTML5/CSS3, SPA, all kinds of Javascript frameworks, ECMAScript 6, HTTP/2, Webcomponents, ServiceWorker, web assembly, ... the list goes on and on.

But, what is a 'Theme'? If you take the word 'theme', it's all about the graphical appearance, nothing else. Basically that's the visible layout, colors, fonts, assets, etc. It's not about the ever evolving web technology.

The 'Theme' thing, the whole as we know now, should be all about the experience for the (end) user. The user's own capabilities, the user's device (form factor, input capabilities, connectivity). And possibilities are enhancing in future.

Or maybe it shouldn't be called 'Theme'. It's getting too big to be responsible for. Some people (like Lombik) already do some form of separation of concern, by inheriting from a base theme. That might work for one situation, but there is a dependency/binding; I don't think you can switch base themes.

Isn't it time to decompose the Orchard 'Theme'?

The theme or graphical appearance is built using layout/zones and other visual aspects. We can have recipes for that. Visual aspects are mostly LESS/SAAS/CSS related.

The processing/rendering in the middle (between shapes and the actual html/css/js) is an intelligent step. That step can(should) incorporate graceful degradation and progressive enhancement (ICYMI - I love this - https://www.youtube.com/watch?v=EVEiIlJSx_Y) and whatever technology/framework you're using, for instance bootstrap 3/4. The technical requirements are all related to this, none to the graphical appearance / theme.

Or maybe this is an opportunity for Orchard2...

DaRosenberg commented 8 years ago

@geertdoornbos Thanks for chiming in! What you're saying makes sense in a lot of ways.

Indeed, I think part of what you're suggesting is what we're trying to accomplish by making the theme "skinnable" or configurable. The technical aspects could then be implemented once, in one single theme, while the pure visuals could be configurable aspects of that theme.

As described in the issue text, we're considering allowing site owners to inject their own custom CSS as configuration of the theme. This is conceptually very similar to what you are describing, right? It basically creates a separation between "theme" and "skin", where the former is about rendering markup and making technology choices, and the latter is about adapting the aesthetics to your taste.

Going even further than that (i.e. formally decomposing the concept of a "theme" into two aspects that are independently selectable) is an interesting thought, but one that I think is better left for O2 or even beyond.

bleroy commented 8 years ago

Finally got time to read all this and answer the summon. Great proposal.

I'd actually deprecate the theme machine, with the goal to remove it entirely, at least in Orchard 2.

I'm in favor of aiming for Bootstrap 4.

More templates?

I'm not super-enthusiastic about putting more templates in the theme. This sounds like a very WordPressy approach, one that we know hurts extensibility, as theme authors have to worry about way too much stuff that is module responsibility. It's common in the WP ecosystem to see themes having to explicitly support this or that well-known plugin. Because trends in plugins shift all the time, themes become obsolete faster, and are harder to use with lesser-known modules.

I think our approach of having neutral templates in the modules that can be overridden by specialized themes is the right one. It does make it a little harder to hunt for the right template to override, but with the help of shape tracing, we win in the end because we have way more flexibility. Notice the distinction between a generic base theme (that has few templates) and a specialized, almost non-reusable derived theme (that has lots of overrides, including for optional module templates). WordPress does not make that distinction nearly well enough.

Should new module templates target the new theme eventually when the theme machine is phased out, or should we just make sure that the existing and new templates are neutral and semantic enough that they work well with TTM, the new theme, and any well-designed theme out there? <- rhetorical question

It may be appropriate to have a couple of overrides built-into the theme for some very core features such as notifications and navigation (because Bootstrap does some interesting stuff with those), but I'd advise against going much farther than that.

Logo and favicon

I disagree with Ryan about logo and favicons: those really aren't site settings. Proof: when you change the theme, will you typically have to change what logo file you use? A: yes, because it must be visually consistent with the theme, so the setting belongs on the theme, not the site. (fun fact: I started by agreeing with Ryan, and changed my mind when I started to try to prove his point).

Zones

I'd vote for less zones, aimed at layout. I'd keep a zone for notifications, footer, and navigation because that is usually outside of what layouts typically address (I guess it would be fun but impractical to have a theme that is just one big zone under the body tag), and because they are not item concerns, but are global.

Users who need more zones can add them: it's easier to add than to remove, and less zones would streamline the experience by showing a clear way to do things instead of confusing new users with multiple solutions to the same problem. I'd cut left and right zones: they should be easy enough to add on a derived theme, and as Daniel showed, there are so many caveats that we won't be able to satisfactorily address in a general theme, but that would be easy choices to make for people enhancing a derived theme.

+1,000,000 on allowing elements to act as zones. Not a new idea, but let's do it already. It does blur the lines between item and global concerns, but this can probably be mitigated using master layouts or whatever those are called.

sebastienros commented 8 years ago

@bleroy About less zones, yes for less, no for no zones. One of the goals of this theme is to provide an out of the box theme that users would use straight away without coding, one that is appealing enough for this. Now imagine a Blog, which is not that uncommon on Orchard (how many do you have?) where do you put an Archive widget if there are no zones for it. If you tell users you want a blog? Create a new theme and add zones. I don't see it as a good offer. And what about controllers that are not using the Layout Part, like Lists, Taxonomies and any custom controller.

I discussed it offline with Daniel and he would agree about having Outer left/right zones, something like this: https://cdn.colorlib.com/wp/wp-content/uploads/sites/2/Entrepreneurship-clean-blog-theme.jpg I would have considered something like this instead https://colorlib.com/wp/wp-content/uploads/sites/2/spike-clean-blog-theme.jpg (where the asides are under the navigation) but it's a compromise that solves the Blog Archives example.

bleroy commented 8 years ago

Where you see problems, I see opportunity ;)

How if blog, list, taxonomy, etc. could actually also use layouts?

The layout template in the theme could also explicitly render a master layout that is site-wide.

Adding zones seems easier on the surface, but let's consider our options here.

sebastienros commented 8 years ago

Processing ...

sebastienros commented 8 years ago

Ok ,doesn't work, with a new Widgets module maybe, but it's not the case today, and out of scope. Another opportunity in mind?

bleroy commented 8 years ago

It's out of scope, yes, until we decide to put it in scope. But yes, it would work best with a new widget editor. I have some ideas on that, let's talk about it for Orchard 2. I'm happy with a compromise for this theme. Left and right sound fine.

DaRosenberg commented 8 years ago

@bleroy Thanks, excellent input!

More templates: Having a default theme that doesn't provide nice rendering of all core functionality would be unacceptable IMO.

The way I see it, we have two options:

  1. As part of this work, tweak the theme-neutral shape templates in core modules to emit truly neutral markup, and make the necessary changes to both TheThemeMachine and the new theme to ensure they render nicely in both.
  2. Leave the theme-neutral shape templates in core modules untouched, and by necessity have more templates in the new theme.

As hinted by your rhetorical question, I think 1 would be preferable.

We might also consider providing the new theme in two layers: one base theme that simply provides the basic overall layout and general styling, and one child theme also adds shape templates for remaining core functionality.

Logo and favicon: You should listen to your first instinct. ;) I agree with Ryan on this. I disagree that the logo changes with the theme. And definitely not the favicon. They are like the site title, only in a different form (image instead of text), and as such I think they belong as site settings.

Zones: I initially thought the same as you, but as @sebastienros mentioned he's convinced me that some longitudinal zones are actually needed and we've reached a compromise. Your idea that the theme layout template could be driven by a predefined master layout which is editable from the admin UI is very interesting though! In combination with designating elements as zones, that could really achieve the ultimate flexibility. But I think we should consider that idea out of scope for this effort - let's start with building a theme for the Orchard of today.

bleroy commented 8 years ago

Devil's advocate on option 1: that may result in breaking changes. Themes that work today could start rendering weirdly.

Not to insist, but really, at least the logo is a theme property: size, proportions, color palette all may vary with the theme.

jtkech commented 8 years ago

I've worked a lot on bootstrap but one year ago, so here it's as i remember.

With .less, jquery and views overriding I could do many things with .less .mixins() and &:extend(), e.g it was quite easy to deal with the content and aside zones sizes, but you can't do all. I've tried some jquery functions to adapt some html structures, but i don't like to mainly use this option. Finally, i've overrided views, e.g to use full bootstrap classes with column elements, but quickly you will have many overriden views to maintain.

Bootstrap I like things as bootstrap when you can say i don't want to be specific but i know that i will use it. This because some concepts become natural and finally required. Then, it can be a guideline e.g for view structures, not to be tied with bootstrap but ready to be bootstrapped as much as possible.

So, here the idea is to mainly use .less files, and each time you need to override a view, try to see if it can be solved by updating the core view without breaking changes. Maybe an useless or missing wrapper tag, a missing attribute to identify a category, a singularity, a different structure for the same thing...

Note: Most of Orchard objects are well formed, but the remaining can cause the main difficulty.

Layouts editor & Zones Maybe zones composition is the responsability of the theme, and layouts editor is at the content item level. But the Welcome page already uses it to make some "zones". Then here the need of the Layout Template feature, but too complex to update items when a shared template is modified, with nested elements...

So, here my feeling is that Layouts is like a framework in a framework and we have to find compromises between two worlds. E.g we could keep the concepts of widgets zones, layer rules, but with the layouts editor experience for zones composition (with some required zones).

Ideally, a theme would only be a style file and maybe some settings for colors, fonts, spacings...

Layout editor & others At the content item level, one approach i had is to use the layouts editor as a general placement tool. And i've worked on TinyMce by making plugins and templates. Here also, to have well adapted structures to be themed and easily become bootstrap objects.

But here also i had the feeling of a mix of 2 frameworks. TinyMce enhancement seemed to me easier but i already felt that it would be better to depend and to do the same with layouts elements. This was a little confirmed with some new simple layouts elements as the Break and the Heading ones.

So, here the same idea to first enhance the ability to create well adapted html structures. This not to use too many workarounds through a theme. E.g a panel element (not sure it's a good example), not as a bootstrap panel but based on the panel concept.

Favicon Seems to be tied e.g to a company, but i agree, you may want a variant when using in a specific theme... Anyway, we need a Favicon that is fully implemented. Not only in the <head> of the document but also as a file served from the site root as requested by some tools. I know how to do that but better if out of the box.

Note: Idem for robots, sitemap and other SEO features.

Finally Sorry if some points are out of scope, and i understand that you have to work with the existing without making breaking changes. But I wanted to present a few ideas I have for some time.

Anyway, great idea, good luck

rtpHarry commented 8 years ago

Based on the conversation in the podcast meeting I wanted to throw in another point of view, that of the noob. The discussion revolved around making a theme that had all the bells and whistles, that could support the marketing style template layout and a more traditional left right col widget area layout.

The consensus was that the theme should support everything. I think it would be fine to do an advanced one but what about the people that just want a simple clean theme for their design?

The problem is that we are just setting up a minefield of options in the theme so that as a developer you are overwhelmed by all the conditional code. It's not easy to trigger every scenario so you can't see how all these combinations are used. Some are mutually exclusive. You need to enable and learn how to use every module in Orchard by the sounds of it because there was discussion about supporting search and other features when they are enabled. This means you don't know what you have to handle and what you can safely strip out for your template.

On the flip side it means that the user/admin is presented with a thousand design options that are "supported" but would blow up in their face and break the design if used.

If you're building a theme to sell then you should have to handle everything but I expect the more likely scenario will be individual developers just trying to build their own site.

In reality an individual site is only likely to use one specific combination and the extra features aren't any use. I know it's not easy to say which features should be in which but a couple of small, simple, opinionated themes would be more useful to people just trying to get started.

dcinzona commented 8 years ago

@rtpHarry I think the thought was that the Theme code would support a lot of functionality, but the recipe selected at setup would populate only the minimal requirements for that function (i.e. blog vs marketing, etc.). That way, if you are building a theme, you can see how the zones interact and work, as well as how recipes can be used to manipulate the theme content and structure.

geertdoornbos commented 8 years ago

Thanks @DanielStolt

Indeed, I think part of what you're suggesting is what we're trying to accomplish by making the theme "skinnable" or configurable. The technical aspects could then be implemented once, in one single theme, while the pure visuals could be configurable aspects of that theme.

I see, the technical and configurable aspects of a theme, would that be something baked into the theme? Or more like a dependency (like Orchard.Resources), a separate module, that can be reused for other themes?

Something to note; you're referring to w3schools for market share. The page says it very clear: 'following figures are based on W3Schools' users, and are extracted from our Browser Statistics'. So the value of 0.6% is very inaccurate. Only devs visit that site :smile: Another source tells a more realistic number I think; https://www.netmarketshare.com/browser-market-share.aspx?qprid=2&qpcustomd=0 where market share is 17.3% for desktop users that use IE <= 10. Statistically 1 out of 5 users. StatCounter says 24% for 'other' browsers than current up-to-date browsers.

Don't know what you think about it, but there is an option to go for Progressive Enhancement, which is a strategy that emphasizes accessibility for everyone, every browser, every connection. I know that is too idealistic perhaps, but you can see it as acting on feature detection. 'html5 support' is easily detectable for instance. You can deal with flexbox support (modernizer) and you'll be able to handle it all the way back to IE6, if you want to (not that you want to). Also, for instance, BS4 can support IE8 with some extra scripts http://v4-alpha.getbootstrap.com/getting-started/browsers-devices/#supporting-internet-explorer-8. So, that could be a configurable aspect of the theme.

Hope you're thoughts are baking and maturing :smile:

DaRosenberg commented 8 years ago

@jtkech Thanks for all the input.

@rtpHarry and @dcinzona Agree with the points made in favor of simplicity. My conclusion from the meeting discussions and a few follow-up conversations with @ryandrewburnett and @sebastienros is that the default theme should favor simplicity, elegance, an appealing first impression, and be somewhat prescriptive. I.e. make some assumptions at the expense of not showcasing all of Orchard's flexibility.

Specifically regarding the zones, we will create OuterLeft and OuterRight zones as per Seb's initial suggestions. These will span the full height of the window, and their contents will be sticky-positioned (scroll-to-fix). They will collapse to vertically stacked on smaller viewports. And they will render with a light border between them and the rest of the page, so the rest of the page won't look weird even if it contains striped sections that span the full width of the page.

@geertdoornbos Indeed, not a good source of statistics to use... :) Thanks for pointing that out. We will obviously need to cater to IE10 users if they are 17% of desktop users. Progressive enhancement is a good principle, but it does not liberate us from the burden of coming up with a defined and implemented behavior for the lower-end experiences. I'm looking to make some trade-offs here for the new theme so we can get something out there that will work on modern browsers, and not have to spend too much time and effort implementing fallback behavior for downlevel browsers.

Skrypt commented 8 years ago

Some ideas could be taken out of this nice Drupal theme tool. https://www.drupal.org/project/omega

roballred commented 7 years ago

Is anything being developed?

sfmskywalker commented 7 years ago

Yes, @ryandrewburnett is working on it.

roballred commented 7 years ago

@sfmskywalker is there a project for it on github?

sfmskywalker commented 7 years ago

Not yet, we're still in the design phase. But once that's done, a repo will soon follow.

DaRosenberg commented 7 years ago

@roballred Not correct @sfmskywalker - theme is being developed in the feature/canopy branch of the main repo. Not many commits yet, but there will be more to come soon hopefully.

sfmskywalker commented 7 years ago

I stand corrected, forgot about that one.