Backend interface: Which browsers should it target?

[DavidOliver]

As Symphony Next will obviously be a while in the making, we may be in the pleasant (and sadly not-more-frequent for many of us!) situation of being able to target currently modern, or maybe even near-future, versions of browsers for the backend interface as opposed to browsers such as IE 9 which can really hold things back.

This could affect decisions made on things such as:

• CSS layout methods (e.g., Flexible Box Layout, which is stabilised specs-wise and the awesomes)
• lots of other CSS considerations
• use of HTML 5 form stuff
• HTML 5 appcache?

So how should we be thinking in terms of browser support, and what recent HTML and CSS features should we assume support for?

I suggest this is a brilliant opportunity to make development and maintenance simpler and quicker by not pandering to what will be out-of-date browsers in a year or so.

[iwyg]

I'd say with regards to IE, IE9 and higher.

[brendo]

We're actually pretty ruthless already in Symphony 2, supporting IE9 or higher. I would think this would stay the same in this version too :)

[nilshoerrmann]

My proposal would be to take the latest releases of all browsers as a starting point for development. Webkit, Blink and Gecko will all release quite a few new versions until Symphony Next will be ready for launch so that'll be fine. Looking at Trident, using IE 10 for development should be just fine because Symphony never actively promoted IE usage for the backend. Making it IE 9 compatible – if needed – could be an additional step, when we have a working prototype (but my guess is, that we could live with out supporting that version).

[DavidOliver]

My proposal would be to take the latest releases of all browsers as a starting point for development. [...] Making it IE 9 compatible – if needed – could be an additional step, when we have a working prototype (but my guess is, that we could live with out supporting that version).

I think that's a good, balanced approach, making development practical while not holding back progress too much. IE9 may fall into the latest-two-versions now, but in a year or so from now hopefully it won't.

The jump to IE10 from 9 feature-wise is a relevant one. IE10 introduces:

• CSS Flexbox layout (albeit old syntax, but still quite usable as far as I know) - it would be great to be able to use a proper layout module for layout rather than floats or inline-block, neither of which were created with proper layout in mind.
• HTML 5 History
• HTML 5 Application cache
• HTML 5 Drag and drop (full)
• Web workers

If we could forget 9 and use some of the above, even if it's mostly CSS considerations to start with, I think it would greatly help speed and improve the backend interface work. So I think Nils' approach is well worth seriously considering.

[jensscherbl]

As far as I know, leaked versions of the "Blue"-service pack for Windows 8 already included early IE11 builds. So it's pretty safe to assume IE10 and IE11 will be the latest two versions at the end of this year.

[michael-e]

So you really think that Windows XP will be gone? (IE 9 is the final version on XP.)

[nilshoerrmann]

No, but I expect the design to be simple enough to make it IE9 compatible. So I just would ignore it during development.

[michael-e]

That's a good approach, sure! (I just wanted to point out that @jensscherbl might be too optimistic regarding IE versions.)

[jensscherbl]

So you really think that Windows XP will be gone? (IE 9 is the final version on XP.)

• IE9 might be the final IE version on XP, but XP can run other (newer) browsers as well.
• Really? I thought IE8 is the final version on XP.
• Official support for XP ends in early 2014. At least that's a good reason for businesses to finally get new stuff.
• I don't see a problem for a CMS (as a piece of software) to have certain requirements.
• If the planned separation between Next's backend and API works out as intended, it wouldn't be that much of a problem to build a dedicated backend for older browsers (or even a desktop app) to support enterprise clients and their outdated infrastructure.

[michael-e]

@jensscherbl: I hate IE like you do, but — as I pointed out more than once — I experienced businesses to be very slow. Good to hear that official support for XP will end; this will hopefully kill IE 7/8/9 all at once, and there will be free beer for everybody when this happens. Until this happens, we can keep @nilshoerrmann's approach in mind.

[DavidOliver]

So it's pretty safe to assume IE10 and IE11 will be the latest two versions at the end of this year.

Yes, that's partly on what I'm basing my suggestion to forget IE9 for Next. I'm not 100% on this, but I think the last stated guideline on browser support from Symphony was the current version plus the previous one.

[...] I expect the design to be simple enough to make it IE9 compatible. So I just would ignore it during development.

As an example, if we used Flexbox layout during development because we were ignoring IE9 and then had to implement layout using floats or inline-block anyway to support IE9 it would be a right pain and potentially make our Flexbox layout work a waste of time. Layout could be one of the simpler issues, of course, compared to the other HTML 5 stuff that might come to be relied upon. So I think it's important to agree as far as is possible on something for Symphony's browser/IE requirements that we can try to stick to, even during this early stage of planning.

I'm with Jens on this in that I think by the time Next is ready it will be entirely reasonable to drop IE9. With several months work ahead, now seems like a good time to aim high and not be held back by what will be very outdated software.

[jensscherbl]

I hate IE like you do

Actually, I don't (well, not that much). IE still has the best font rendering on windows... ;)

[lewiswharf]

My vote is for IE9+

[michael-e]

IE still has the best font rendering on windows

:-) Agreed on that. It's just that ancient, buggy versions are around so long. This has been a serious brake shoe for web development.

My vote is for IE9+

It will take while to build Sym Next, so let's follow @nilshoerrmann's proposal. If IE9 is still around when Sym Next reaches alpha, we can probably make it fit.

[brendo]

Keep in mind that with a mobile first philosophy, it is very likely that the browser that will be the pain point will be actually be Android 2.3 or Opera Mini. I don't anticipate too many problems though, because tools like Modernizr will allow us to build an interface that scales up depending on browser support.

[DavidOliver]

Good points to consider, though I don't think a mobile-first approach in our context/as I meant it means we have to support all mobile browsers. It's a CMS/app (not a public-facing, informational website), which will have to have certain minimum requirements of our choosing whatever device type the user is using.

But based on the responses here, are we agreed not to worry about what will be old browsers during initial iterations, making sure it works in current versions of most browsers (IE 10), and to then come back to deciding on things when Next is at alpha stage?

[designermonkey]

When choosing a mobile first approach for an admin, I would suggest that we limit it to tablet sized devices, and reproduce the tablet layout on mobile, so a little downscaling visually will occur for phones, but like @DavidOliver says, we will need minimum requirements for support. I wouldn't admin a site on anything less than my iPad mini personally.

[DavidOliver]

Well that's pretty much how the current Symphony works. But I think as long as the UI people approach it right, making the backend interface work on mobiles is very doable, and desirable especially for content editing by authors. See #3.

[nilshoerrmann]

Content editing using phones shouldn't be hard to achieve.

[nilshoerrmann]

@DavidOliver: Are you in for working on the UI?

[DavidOliver]

@nilshoerrmann, yes, if that's okay. I don't think I'm here for my über-noober PHP skillz. :-)

[nilshoerrmann]

yes, if that's okay.

Well, of course – we need to form a small team for that task :) Who else is in?

[jensscherbl]

Would building Next's UI with Bootstrap 3 be a good idea? It'll be mobile first, by the way.

It already looks pretty nice and similar to Symphony 2.3. Besides, this would bring some of the same advantages of a server side framework to the UI as well (more basic stuff already developed and tested, good documentation, etc.).

[bernardodiasc]

Hi @nilshoerrmann , just for curiosity, is the plan follow the current UI and just make it flexible or rebuild everything including UX?

@jensscherbl please don't use Bootstrap! It's great for fast interface development, but maintain is painful.

[jensscherbl]

Please don't use Bootstrap! It's great for fast interface development, but maintain is painful.

Just a thought... ;) Can you give a few examples of its disadvantages?

[iwyg]

I love http://foundation.zurb.com/

[DavidOliver]

I've so far stayed away from using complete frontend frameworks, but I have previously read a bit on and like the look of Foundation.

[nilshoerrmann]

Would building Next's UI with Bootstrap 3 be a good idea?

Personally, I don't want to use Bootstrap for the UI.

Symphony Next is not about using frameworks everywhere. It's about getting rid of development work that's not in our main focus area. The Symphony UI and workflow is one of the main selling points of the system.

The UI is an area Symphony has always been outstanding in. This is something we should handcraft. Lean, simple and without additional ballast.

Hi @nilshoerrmann , just for curiosity, is the plan follow the current UI and just make it flexible or rebuild everything including UX?

Symphony Next is a good starting point to rebuild the UI from ground up. That doesn't mean that things will look completely different but I really think there are a lot of area that we can handle more elegantly today (section editor, data source editor etc.).

Symphony Next doesn't have to be backwards compatible which allows us to change the markup and reorganise our styles. People often think this has all been rewritten for Symphony 2.3. It has not because of backwards compatibility for extensions – so especially the stylesheets are quite messy and way to specific.

I love http://foundation.zurb.com/

Foundation is great. I love it. Still I don't think we should use a UI framework in its entirety but we should take bits and pieces we like and need.

[iwyg]

That's the beauty of it.

[DavidOliver]

That's the beauty of it.

Do you mean that you get to use only what you want?

[nilshoerrmann]

By the way, the biggest issues we had with the UI over the last years are related to two things in my eyes:

• backwards compatibility with extensions and
• missing underlying core structures and functionalities.

Backward compatibility is a problem when thinking about widgets like the Duplicators: we couldn't just change the underlying markup or the element the plugin is applied to because this would have broken all extensions relying on Duplicators. This resulted in two different APIs: the old and the new one. The script and style files are quite bloated in the related areas.

Thinking about core functionalities: We have an UI concept for an updated Data Source editor since two year I think. It couldn't be implemented yet because of the way Symphony works under the hood, because mayor parts need to be rewritten.

[nilshoerrmann]

Do you mean that you get to use only what you want?

You can customize your build: http://foundation.zurb.com/download.php

[bernardodiasc]

I like Bootstrap, but sometimes loads too much stuff. If we need to get some more peculiar things can be ugly and also hard to update. Said that I don't recomend any CSS Framework for the Symphony UI...

@nilshoerrmann the actual UI is pretty beautiful, the experience too. Always have some to improve, but in this visual parts is better to go more conservative... I just afraid to have the CMS decharacterized if drastic changes to be made.

[jensscherbl]

Who else is in?

I'd like to help with testing, provide feedback and make suggestions, but stay out of the actual UI development, if that's ok? Maybe I can also help with JavaScript if you get stuck and need help on specific issues.

You can customize your build:

Same with Bootstrap... ;)

http://twitter.github.io/bootstrap/customize.html

[iwyg]

Do you mean that you get to use only what you want?

yes, since it's more or less just a compass extension. You can easily configure it in a bootstrap file, pick only stuff you need etc.

[nilshoerrmann]

I just afraid to have the CMS decharacterized if drastic changes to be made.

Did you have the same feeling when we moved from Symphony 2.2 to 2.3? We changed a lot of things visually but I still think you immediately recognize Symphony. There are even a few reminiscences to Symphony 1.7.

As I wrote above: starting from scratch doesn't mean things will have to look that much different. I think we will be able to simplify a lot of things and adjust a few concepts. Think of the section editor: why do can't I edit field settings the content area itself? Can't we find better ways to administer our content?

[designermonkey]

I re-organised Symphony's teams and members (hence the WG email recently), and currently, the UX/UI team has:

@DavidOliver, @nils-werner, @nilshoerrmann, and @johannahoerrmann

If there are any more members for the team, please let me know at: john@designermonkey.co.uk, and I will ensure you're added and receive the same rules email I sent recently.

[bernardodiasc]

@nilshoerrmann nope, 2.2 to 2.3 was awesome. The simplicity of the CMS only got better.

We changed a lot of things visually but I still think you immediately recognize Symphony.

That's the point. =]

Perhaps contradictory to my opinion about conservativeness, but something like this can serve as a reference for UX improvement: http://getsymphony.com/discuss/blog/entry/improving-the-section-editor/

The concept is pretty cool, and I also think it is possible to simplify.

[bernardodiasc]

I mean, not the Section Editor is the point, I refer more to the possibility to get something other than 2 columns on Entry Editor. Thinking mobile-first this is in some way relative.

[designermonkey]

Bootstrap vs Foundation.

This brings about the question: Which shall we use? SASS or Less? We have to use a pre-processor here, it just makes sense, and that will ensure that we minify and concatenate all our styles before release. Personally I am a Less man, and I have built a simple starter kit for all this stuff, which takes lots of cues from many frameworks and kits out there.

I always stay away from big frameworks, and always try to endanger an attitude of 'build what you need' into every project myself and my team work on, hence the 'starter kit' of tools rather than loads of left over code that is unused.

If you're interested in using it, it's here (due a couple of updates)

[nilshoerrmann]

I mean, not the Section Editor is the point, I refer more to the possibility to get more than 2 columns on Entry Editor. Thinking mobile-first this is in some way relative.

Yes, this is one of the area Symphony could be improved greatly. And this is why I said, we should start from scratch because it allows us to make the markup and CSS future-proof.

[iwyg]

The concept is pretty cool, and I also think it is possible to simplify.

This is exactly what I was thinking of.

BTW. I know it's no up to me, but can we just get rid of the dropshadow and shiny stuff?

[designermonkey]

possibility to get more than 2 columns

This was a feature of Symphony3, and should definitely be ported over. We shouldn't forget that little project as (even though the underlying code was squiffy), there were some killer enhancements there.

[designermonkey]

BTW. I know it's no up to me, but can we just get rid of the dropshadow and shiny stuff?

lolz. I agree though.

[lewiswharf]

BTW. I know it's no up to me, but can we just get rid of the dropshadow and shiny stuff?

Agree :)

[michael-e]

+1

[DavidOliver]

Before we get too far into these pre-processing and framework decisions, I think we need to get the purpose of this issue agreed:

But based on the responses here, are we agreed not to worry about what will be old browsers during initial iterations, making sure it works in current versions of most browsers (IE 10), and to then come back to deciding on things when Next is at alpha stage?

[nilshoerrmann]

Which shall we use? SASS or Less?

We had this discussion when working on Factory. There was no consensus (although the majority was for SASS) and we decided to not use a preprocessor because CSS is the language every web designer understands.

BTW. I know it's no up to me, but can we just get rid of the dropshadow and shiny stuff?

Yeah, I think we all agree here.

[nilshoerrmann]

I think we need to get the purpose of this issue agreed.

I thought we already agreed on that, too :)

[iwyg]

ha!