I am designing a web app from scratch, which would be a fluid-based layout and the same HTML would render on different screens using the adaptive CSS.
I am going to use adaptive CSS (or responsive design) for this.
I was looking to use a framework like SCSS (http://sass-lang.com/) which would improve my code maintenance efforts. I'll have lots of CSS files (and probably some skin based as well)
Since I am using adaptive layout, I am going to use CSS Media Queries for desktop/tablet/mobile CSS. I could not get an idea how well the SCSS would integrate with media queries and overall speaking , how much flexibility will it offer to me.
Please let me know your suggestions if you have used SASS/SCSS and in general, any other suggestions.
SCSS is essentially an extension to CSS, and is useful (with mixins) to void repetition in your code. It also provides a way to group blocks of CSS in semantically meaningful ways and gives you variables to avoid repeating yourself.
If you are using a framework such as Rails, it is no-brainer.
There are also frameworks which focus on layout such as 960 (and its variants), and Blueprint which also adds code for thing like buttons.
The underlying philosophy behind many of these is DRY (don't repeat yourself). One bonus of using an established framework is that many of the browser issues have been ironed out, so you can be sure that it will work cross-browser.
It is true that perhaps the code is not quite a lean as rolling your own, but with careful editing and making sure you minify the result and send it gzipped, this is not a major issue except on the most high traffic sites.
Personally I have objected to using frameworks in the past because of the small amount of additional redundant code, but after 15 years of hacking around browser issues, I now think they are a Good Thing.
Larry Wall said in Programming Perl, "We will encourage you to develop the three great virtues of a programmer: laziness, impatience, and hubris."
Anything that allows more people to use CSS in a repeatable and reliable way, to build on work done by other, and to try out some of the leading edge features has got be a good thing.
Engineering a site with media queries is still a bit leading edge. There are compromises in each approach and you should read up as much as possible before choosing one. Adapt.js is a good alternative if you don't mind javascript.
You may want to look into the HTML5 Boilerplate. This has some useful defaults, and lots of documentation about the HTML and CSS defaults that have been chosen.
Good luck!
I have not used media queries together with SCSS, but I don't think they conflict with each other. I have used SCSS extensively in my current rails apps, and it helped me to reduce the amount of code, and get a better understanding when to use which styles.
The tricky part will be what to have fluid (changing depending on the medias viewport size), and how to avoid repetition.
Have a look at the nice site Responsive Design with CSS3 Media Queries, to get an idea which parts of your layout may be fluid.
Have a look at 320+Susy (GitHub repo here). It uses the Susy grid framework extension for Compass. All of these tools are based on Sass and make use of media queries.
Related
I'm re-building a static business site for myself. I've spent a month learning and working with many frameworks (Bootstrap, Foundation, various grids, layouts, themplates, etc.). Most go way overboard (Wordpress), cause slow loading times and are hard to adapt. And, I really don't have time to learn sass, less, etc - though I wish I could (and maybe will).
I'm looking for anyone's advice here - what would you use? No CMS needed, accordions/tabs/sliders would be nice for better ordering/gallery pages, pretty straightforward layout as seen in my link below. I do realize this is a whole new build/design world now, but just in the past month, I've been approached 4 times by folks like me who also wonder what to do...and they're either giving up or going with Wordpress.
Though reticent to admit that my site still uses tables (gack!! - hey I have 2 jobs...), here's the link.
Sorry, but it just seems like you can either take an easy way with all the bloat, or it's really hard. Will this all be different a year from now (especially the gap in between)? Just frustrated...
Thanks so much!
~Lauren
What are your problems with Bootstrap (or Foundation, I suppose -- just replace "Less" below with "Sass")?
You mentioned being opposed to learning Less -- but you don't have to use it yourself to use Bootstrap (BS): just pull in the CSS files and use BS classes in your markup. If you need more styling, write your own CSS file and pull it in separately.
I thought Bootstrap might be a good solution for you because it provides the UI components that you would like (you mention accordion/tabs/sliders) and it is pretty easy to follow along with the examples in the BS documentation, reproducing the required markup. Depending on how much you want to customize the styling, you could produce a nice, functional static site pretty quickly.
I typically work on web apps that will only be used by a small group of well-controlled people, but now find that I'm writing something that has the potential to be used by a very large population. This means that the design and "look" will be very important to the success.
While I can certainly code up something functional, it ain't gonna look pretty, so I know that I'll need to get an outside designer to make things look good. Never having worked that way before I had a few questions about the mechanics of how this happens and how to try to make things easier.
We do Java, so when building a rich interface, we use GWT. I know that when working with designers, they typically provide images of what the interface should look like without any type of "useable" output. My question is how best to bridge that gap between a simple drawing of an interface to a fully functional realized one.
Any thoughts are appreciated.
Well, "it depends", as always.
Nowadays, I don't think you can work wit someone who simply provides PhotoShop mockups. At least not at your level. Mockups are simply too static, and translating those mockups to actual pages that actually work with different browsers properly is a skill set all its own.
So, you need someone beyond simply a designer, especially if you are planning any javascript wizardry, animations, or other dynamic elements that don't capture at all well on a static image.
What you really want is an "operational" mockup. Static HTML files that look and behave as best as can be done to what the UI designer wants to do, including transitions, work flow, etc. This artifact can be run through all of the stake holders as a live mockup, letting folks "Feel" the site.
Once you have these HTML files, you can then do your part of backfilling these pages with actual server side content. Obviously you can start early working on models and working with the designers so as to have services ready to support the site functionality, but you shouldn't be committing any real time in to actual pages for the site.
As for interacting with the designers, I talk more about that over here: How can I make my JSP project easier for a designer to work with
I worked on a project very much like this. We had "comps" which were pictures of what the interface would look like. We identified common objects and build modules. Then built pages (this was for a web app) from modules plus any elements that were unique to that "comp".
A couple things to keep in mind that will make life much easier: use the comps/drawings as more of a recommendation rather than set in stone design. Try to identify common pieces early on and reuse code.
Also, designers aren't user experience gods. They often have a good idea of how things should work, but if you are close to your product and have a lot of product knowledge, don't be afraid to tweak the design as you and your group see fit. One thing that designers typically lack is product knowledge. They know a lot about general user experience and how a site should work, but they often won't know the in's and out's of your use cases and products.
If you are working with GWT, you should look for designers who are expert in CSS. Apart from, may be, the main layout of the website, all the application components like form fields, dialogs, tabs and grids etc. will need to be styled using CSS.
If the designers are not experienced in working with GWT, share the GWT's documentation about styling with them. It's a good idea to read these yourself as well. Specifically explore the GWT's theme-ing system.
Also try to make use of UiBinder as much as possible. This would allow you to stay as close to traditional HTML based design while still enjoying the GWT high level object oriented interfaces (both widgets and DOM).
Optionally you might want to tell the designers that GWT image bundles will automatically do "CSS Sprites" so they don't need to worry about page load performance issues related to images.
This question has been asked in various guises. However. this is a slightly different take on things. By web application, I mean an ultra lightweight frontend - ideally an HTML page with form and regular buttons, with as little dependence on heavyweight JS libraries like jQuery as possible.
The goal is simple. I want to write a simple forms based application for use accross various mobile devices. I thought going the HTML route would be the simpler route (since browsers get around the whole cross platform issue) but even the browser approach seems problematic because of differing screen sizes on mobiles.
I have two questions:
For a simple form based application like I have in mind (possible 3-4 screens in total), I think the browser based approach gives more bang for my buck - am I missing a trick?
Are there any resources that someone can point me to for:
a useful reference for minimum (i.e. lowest common denominator) window size (I forget the technical term for the visible part of a page)
perhaps an example that will show a simple HTML page that will render correctly accross multiple devices?
The HTML5 mobile boilerplate will probably answer a lot of the questions about how to best get things to work across browsers:
http://html5boilerplate.com/mobile/
They have example markup and template implementations for things like browser/device specific CSS hacks, getting a custom launcher icon across different device styles, and implementing offline digest.
You really need to answer two questions before you pick a platform. First, what mobile devices and/or device capabilities are your lowest common denominator? There are lots of variable capabilities between most of those platforms -- screen size, input method, platform speed and mobile platform to name a few. Second, what is your connection requirement? Completely different issue building something targeting spotty or no connectivity versus a fully connected app.
Then you can start thinking about what tool(s) might get you there. In general, a very, very simple HTML site will look okish on most platforms you list. I wouldn't roll with HTML5 functionality because you've got serious limitations there. And HTML/web apps are kind of moot if you need things to work with limited connectivity.
iOS (webkit), Android (webkit) and BB OS6 (webkit-ish), are fairly easy to develop for.
Windows 7 should be, but who knows? They aren't promising HTML5 support until end of year.
BB OS5 browser sucks if you hope to be doing DOM manipulation or fancy JS event listeners. It's really buggy.
Nokia...it's a crap shoot. Granted, they have about one year left before they ditch their OS anyways.
Screen sizes are an issue, as is the fact you can change the orientation. But that can be gotten around with some careful planning.
HTML5/CSS/JS is definitely the way forward for making cross-platform apps as easy as possible...be it in the browser, or as a compiled app.
Hey all, this is more of a philosophy question than anything. I have written my first web app, a Boston event calendar at http://bloozit.com I wrote it in Python, and I'm pretty happy with the simplicity of it, however, my Python contains blobs of HTML, CSS, and Javascript, like a stew with fish heads and eyeballs floating in it.
Then I saw this tutorial on web apps using Lisp: http://www.adampetersen.se/articles/lispweb.htm I've read On Lisp and written some software in Lisp, so I'm no Paul Graham, but I am familiar with it. One thing that appealed to me tremendously was how the author generated both the HTML and the Javascript from Lisp, makingn the whole thing nice and homogeneous.
The question is, how valuable is that homogeneity in the real world? Whenever anything goes wrong, you have to load the page up in Firebug, and then you'll be looking at the generated HTML, CSS, and Javascript, not the Lisp source, so you have to hold the mapping in your head. Does the homogeneity provided by Lisp really solve anything, or just wallpaper over the problem, which eventually pops up again downstream?
If there's anyone out there who's actually tried both approaches, I'd REALLY like to hear from you!
Well, I spent a year coding with parenscript and ht-ajax and eventually gave up and just generated the javascript by hand (still using hunchentoot on the server). I found that the result was much more predictable and, as you imply in your question, this made it a lot easier to figure out what was going on when using firebug. (I also switched to using jquery, which was much better than ht-ajax, but that's not really what you're asking).
That said, I massively recommend cl-who (http://weitz.de/cl-who/), which makes the dynamic generation of HTML much neater.
The question is, how valuable is that homogeneity in the real world?
Probably fairly significant: look at all the people doing server-side Javascript these days. Javascript isn't superlative at anything, and its library support for server-side code isn't that great at all, but there's big gains to be had by using it.
Whenever anything goes wrong, you have to load the page up in Firebug,
Depends on what the "anything" is. I can't actually remember the last time I had to open up Firebug to see what's going wrong -- I've certainly been through phases where it was, but there's also plenty of times when it's not.
For example, if you generate your CSS from s-exps, then trouble with your CSS might only make you need to look at the "compiled" CSS for weird syntax issues (like IE6 tricks). If you just look at the page and decide you need an extra border, then you can add (:border 1) and be done with it. (Of course, if you process that to generate a whole set of CSS rules to serve to the client, then it's an even bigger win.)
Another way to think about it: on very rare occasions I've needed to pull out a packet sniffer and a disassembler when working on a modern web app. Yeah, it sucks, but with good libraries, it's also very uncommon. I wouldn't rather write low-level code all day just to avoid the impedance mismatch of switching to a packet sniffer on the rare occasion when I do need that level of information.
This assumes that you want to and can get to a level where you're writing (V)HLL code. Common Lisp can't beat C at being C, and if you're just trying to spit out a simple blog in HTML then you're not in the sweet spot there, either: Rails is really good at that kind of thing already. But there's plenty of experimental programming where being able to change one flag and run code on the client rather than the server is useful.
and then you'll be looking at the generated HTML, CSS, and Javascript, not the Lisp source, so you have to hold the mapping in your head. Does the homogeneity provided by Lisp really solve anything, or just wallpaper over the problem, which eventually pops up again downstream?
I've written all-Lisp and all-Javascript web apps, and I think the best answer I can give right now is: it could. I've used Parenscript, and the major problem is that Parenscript is a Lisp-y language but it's not Common Lisp, nor is it any other complete language you can use on the server side. (If there was a Common Lisp to Javascript compiler, like GWT is for Java, then it'd be great. I don't see anyone seriously trying to make one, though.) So you've still got, as you observe, two languages.
Javascript is a bit better today, in this regard, because you can run exactly the same code in both places. It's not quite ideal because your server-side Javascript probably has features that you can't guarantee will exist on the client-side (unless you limit your users to, say, recent versions of Firefox). If you're like me, you don't want to limit your server code to JS that happens to run in every browser, so your server-side JS and client-side JS will be subtlety different. It's not a dealbreaker -- it's still pretty nice -- but it's still 2 slightly different languages.
I think it would be pretty cool if there was a program that could take code written in the latest Javascript (1.8.5), and generated old-school Javascript that ran in any browser. I don't think that such a program exists, but I don't know how difficult it'd be.
There are Scheme implementations for Javascript, and so maybe the situation with Scheme is better. I should probably look into that one of these days.
I'm often frustrated when having to use a server-side language that's completely different from my client-side language (Javascript). But then I'm also frustrated when I have to use a language that is lower-level than Lisp (which is most of them). Is it a bigger win to be more Lisp-like, or more Javascript-like? I don't know. I wish I didn't have to choose.
This isn't so much an answer as a strong opinion, but the fundamental problem is that HTML and CSS are just terrible(1). Neither does well what it is supposedly intended to do. Javascript is better, and is often pressed into service to make up for the shortcomings of those two(2), but it isn't an ideal solution(3). And as result server side languages are needed to generate HTML and CSS which just further complicates the mess. It is laughable that the simplest web application requires programming in no less than four different languages.
So, yes, your desire to have one good reliable language which which you can interface instead of those others is understandable, but so long as you are writing code that generates HTML/CSS such that you have to be concerned with the details of HTML and CSS, then you are just wearing mittens that might (read "probably") interfere when you go to play the piano. If your Lisp code is looking like this: (:body (:div (:# (:style (:border "1"))) (:p "hello"))), then you aren't really free from the concerns that plague you.
Personally, I think we need something else to take the place of the soup we've got now and it should compile to HTML/CSS/JS but keep the user free from their concerns. C compiles to assembly but the C programmer never sees the STA, MOV, LDX opcodes that it compiles to in their own written code. And, were it to be popular, then the browsers could support it directly. Anyway, it's just an idea. A glimmer.
Good Luck,
Chris Perkins
medialab.com
(1) HTML documents are compound documents with images, scripts, stylesheets, etc all being stored in other files. But the one thing that an HTML document cannot do is fluidly embed another HTML document - the one thing it most needs. iframes/object tags are fixed size and both adversely impact SEO. This one trivial task is often the sole reason a server side language like PHP is used on many websites.
You don't need me to tell you how bad CSS is.
(2) Examples abound: LESS (lesscss.org), document.write, AJAX, and more.
(3) The impedence mismatch between the Javascript DOM and CSS rules is nearly unbelievable. How many heights does a div have in the DOM (scrollHeight, offsetHeight, clientHeight, and more)? 4 or more, maybe? How many of those are addressable via CSS? 0 or 1.
Also, while Javascript can plug a lot of holes, it often does so at the expense of SEO
I've worked with several different types of "user-generated content" sites: wikis, a message board, blogs... These systems can differ greatly: a blog post editor allows more control over presentation than that for comments on the blog post, a wiki topic editor encourages wiki links over raw URLs, etc.
However, one key design decision is common to each: should I provide the user with a simplified markup language such as Wikitext, Markdown or BBCode, forcing users to learn that, or should I give them a WYSIWYG editor like CKEdit or TinyMCE and filter or transform the resulting HTML behind the scenes?
There was a time when I thought this was a simple matter of identifying my intended audience: tech-minded users get markup, non-technical get WYSIWYG. In practice, this hasn't worked out all that well, occasional users struggling with markup and the WYSIWYG editors providing at best a leaky abstraction for the underlying HTML.
So with my initial confidence throughly crushed, I come looking for advice:
What factors should I be taking into account when making this decision?
Have simple markup systems become commonplace enough that I can rely on most users having at least some familiarity with them?
...Or should I abandon them as merely a relic of the past, and work on finding ways to make WYSIWYG work more effectively...?
I'm not looking to go back and tear apart what I've already done. For better or worse, these systems are working, their few users comfortable or at least competent by now. But it would be nice to have some better guidelines when putting together future designs.
One approach that seems to work fairly well is the use of Markdown as done here on SO. Stupid and/or lazy people (with apologies to all who are) can simply throw text in the box; it comes out looking as messy but it's mostly there and readable. People who care about how their text looks can do some simple things that are for the most part almost intuitive (like leaving blank lines between paragraphs, putting asterisks or numbers before list items) and it Just Works™
This is Good Enough™ for a lot of applications and people. Some of the glitzier sites, such as Google Blogs, give you your choice (changeable at the click of a button) of editing raw HTML or using a WYSIWYG editor (that fails just often enough that I usually opt for raw HTML). In theory, you could even give your users 3 alternatives, such as Markdown, HTML and WYSIWYG; but at some point you'll be wondering why you even bothered. Some users will always struggle with some aspect of the interface and they'll blame you. I believe in finding a happy medium and not bothering to make everybody happy.
From my point of view, the most important considerations are those of security. If you allow raw HTML, your users can insert spam and malware and basically hijack your site for their purposes; so you have to carefully limit what's allowed. Another consideration is that if you allow, e.g. H1 headers, people can take up a lot of space and attention with posts that should really be subordinate. If you allow CSS (including style attributes in HTML tags) then again there are ways to deface your "real" content. Another big problem stems from unclosed or unmatched tags. These are the really serious problems, and you want to err on the side of strictness to avoid more serious problems.
"What factors should I be taking into account when making this decision?" What do your customers want? Can you not have a 'fall back' kind of system where the 'simplified' WYSIWYG can be used until they need the added features of raw markup? What kinds of things do the most users use most often? What features are used less often but, when they are needed, you customers cannot live without?
"Have simple markup systems become commonplace enough that I can rely on most users having at least some familiarity with them?" For people using wikis and blogs, I think the answer is yes. Even commenters on blogs to some extent for the simplest things but again, I think you should let them do markup in-line if they are able (or some common sub set of markup) and have the option of more power if they need it.
"..Or should I abandon them as merely a relic of the past, and work on finding ways to make WYSIWYG work more effectively...?" I would not take this all on at once. Work from a solid kernel of functionality and work outward to a complete system.