Backend interface: Which browsers should it target? #2
Comments
|
I'd say with regards to IE, IE9 and higher. |
|
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 :) |
|
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). |
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:
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. |
|
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. |
|
So you really think that Windows XP will be gone? (IE 9 is the final version on XP.) |
|
No, but I expect the design to be simple enough to make it IE9 compatible. So I just would ignore it during development. |
|
That's a good approach, sure! (I just wanted to point out that @jensscherbl might be too optimistic regarding IE versions.) |
|
|
@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. |
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.
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. |
Actually, I don't (well, not that much). IE still has the best font rendering on windows... ;) |
|
My vote is for IE9+ |
:-) Agreed on that. It's just that ancient, buggy versions are around so long. This has been a serious brake shoe for web development.
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. |
|
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. |
|
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? |
|
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. |
|
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. |
|
Content editing using phones shouldn't be hard to achieve. |
|
@DavidOliver: Are you in for working on the UI? |
|
@nilshoerrmann, yes, if that's okay. I don't think I'm here for my über-noober PHP skillz. :-) |
Well, of course – we need to form a small team for that task :) |
|
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.). |
|
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. |
Just a thought... ;) Can you give a few examples of its disadvantages? |
|
I love http://foundation.zurb.com/ |
|
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. |
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.
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.
Foundation is great. I love it. |
|
That's the beauty of it. |
Do you mean that you get to use only what you want? |
:D Okay, it's agreed then. I wanted to make sure. Re. pre-processors, I agree with @designermonkey - they save so much time (once you've got over the little speed bump of setting it up) and make things immeasurably more maintainable.
+1 ;-) |
|
@nilshoerrmann, I use Sass so far. |
|
I'll start putting browsers minimum requirements clauses in contracts... In this right moment I think some client is trying to access a beta website with some old motherfucker IE =( I'm using Less here, but I know Sass is better. Less was so easy to make it work (with lessc)... |
You two share a single vote! lol |
Hey, we are married, not the same person. We have two votes! |
|
You are a "We" |
I agree and personally like the currently trendy "flat" or "metro" designs a lot (if done right). But also keep in mind that being too extreme in both directions is bad. Sometimes it just makes sense (even in a flat design) to have subtle shadows or other hints to distinguish certain elements or interactions. While I'm a big fan of Microsoft's new design direction, somtimes they've taken it a step too far in Windows (Phone) 8, making stuff a little difficult to use or leading to visual clutter, even though everything is flat and minimalistic.
From http://daringfireball.net/2013/01/the_trend_against_skeuomorphism |
|
I know flat design is currently en vogue. But It's actually bringing the meaning of design back to the web: communication through structure. |
We haz 2 votez. |
I just checked with my wife. She said 1 vote and it's all @johannahoerrmann LOLz |
Everthing old becomes new again at some point.
Agree. Its correct for the medium because it emphasizes structure and content. |
+1 Wise to agree! |
Dreamer. 1 vote per family, that's the rule. |
__lol** Don't let Johanna hear that! Can someone please deactivate email notifications for her account? |
Sure thing. As already mentioned, I'm a big proponent, but it has to be done right. I'd opt for an almost flat design.
|
|
and we need circles!!! Lots of them! |
|
Let's just design, right? Main question discussed with agreement. A lot of other things discussed. Closing this issue. |
|
Wenn der Designer mal nichts weiß, malt er einen Kreis – ja, ja, ja :) |
|
👍 |
|
Naja, bei uns hieß das, wenn einem nix einfällt, macht man nen Veraluf. |
|
what do you think of AngularJS? [edit] ops, this issue is already closed... there will be some discussion about it? |
|
It's interesting but what should we use it for? Am 17.04.2013 um 17:38 schrieb Bernardo Cruz [email protected]:
|
|
I just play a bit with Angular, make it too easy to manipulate DOM. I imagine this on Data Source Editor and mainly on Section Editor. |
|
This issue is way closed, but just to couple: I love to use SASS with Compass, initially on behalf of the Foundation, but I also went for only build-in mixins from Compass itself (normalization, css3 a.s.f.), added to test out Bourbon, and for the grid Zen Grids as of now, to be far more lightweight and independent for the change. The grid works down to IE8 and its rather elegant to use, semantic too. Besides that I create some simple mixins as needed, its nice to do with SASS. I should be doing a responsive project in the upcomming weeks with this setup (with Symphony that is too) and will want to share it in Symphony's showcase, if all goes well. I initialy came to CSS preprocesors through LESS, which primary helped me to get quite fast in love with this approach, but went for SASS afterwards. |
Currently switching as well. |
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:
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.
The text was updated successfully, but these errors were encountered: