I know there are several tools available to find unused CSS on a static web page. But in most real world scenarios I encounter, a lot of the CSS is used after some or the other interaction on the page, maybe a new modal opening up or an options popup etc.
In such scenarios, what would you suggest? How do I keep a tab on my ever-growing render blocking CSS?
The only way I guess one could do that is by running regular unused-css-detector type tools in conjunction with Selenium - test known interactions and see whats left unused. But a big assumption here is that I'd need to know all interactions on my page which could use new CSS. Is there a way to achieve my goal without making this assumption?
In an ideal world, I'd be able to post-back all CSS used by a visitor's browser on my page to my server. Then I'd collect data over a month, aggregate, and get a pretty accurate idea about actual unused CSS.
Any good ideas?
I am the author of a tool that is aiming at doing what you are describing. Everywhere I worked, the CSS is this "append-only" thing that is too risky, too time-consuming to clean up. And even when you try, the ROI is so low that it not worth it.
So I am working on a tool that is very similar to what you are describing. The goal is to bring confidence on what can be removed, and to actually do it automatically by submitting pull requests.
A snippet of JavaScript is running in the browser and sends reports of what is being used to a server. Once enough data is accumulated to build some "confidence score", it can create Pull Request automatically to remove selectors that are actually not used.
It is still very early stage, but you are welcome to try it and give some feedback about it.
https://www.bleachcss.com/
Related
Does anyone know if I can integrate GrapeJS into my own website so clients could build their own websites using it? IF anyone has done this, how easy is it and are there downsides?
This question is pretty open ended, but I'll take a shot at it.
The short answer is yes, you can use Grapesjs to allow clients to make their own sites; however, the details matter.
Grapesjs by default doesn't know anything about your stack, website structure, metadata, etc. You will need to either supply plugins or implement those features yourself. I've worked on a project for a company that used Grapesjs to implement single page apps and I'll include just some of the tweaks we had to manage.
Hiding certain layers that only confuse average users.
Hiding pretty much all of the styling, and using traits to allow people to pick from some predefined styles.
Take the html, css on store and generate the final html page, and store it in our static serving folder on the server.
Implement a wrapping "App" component that has traits for the different metadata we want users to control (open graph metadata, title, etc)
and those are just the big things, I'm sure I am forgetting several small ones.
For your application, you'll also need to implement a custom trait for links / buttons that allows you to link from one "page" to another. As well as, a way to allow a user to pick which page to work on.
The long answer is Yes, but Grapesjs is only the starting point.
Yes you can.
However it is not straightforward.
If you want to build a Drag Drop Editor like GrapeJS Demo, here is the Source Code - https://github.com/artf/grapesjs-preset-webpage
You can see an implementation at https://codegres.org/dragdrop
I like them more and wonder why they are not more common. Explanations involving caching or SEO make sense to me, but I don't see them as directly driven by user experience considerations. In which way are traditional sites with page reloads better for the user?
Personally I think the best argument for normal page reloads from a user's perspective is that when you do that it's much harder to break many basic browser functions. In general the back/forward buttons work, bookmarking works, copying and pasting links works, history works, page titles work, getting an error page when a server call fails works, everything just works as expected. For free.
I have seen single page application implemented in a way that breaks one or more of the above more times than I can count.
It's naturally not a problem if you get it just right (and then it will in general be nicer to use), but not all sites do.
Just as an example here's a screenshot how a site that is a SPA and justifiedly so (they have a music player that you don't want to interrupt with page loads), broke a basic browser function in a way they might not even have thought of. I was trying to find a song I recently listened to but couldn't remember the exact title... but because of the SPAness the page titles weren't properly reflected in my browser history.
On this page, I want to get my scrolling dinosaur name window to specifically keep that dinosaurs name at the top so the person doesn't have to scroll all the way down to the next dinosaur.
I also want to know if there's an easier way to do this window.
My predicament is this....
I have over 30 dinosaurs on here. Each time I add a new one I have to update each and every one of the dinosaurs pages to add that one new dinosaur. Its not really time effective... Is there a better way without having to use frames?
My code is open so you can look at it and modify it at your leasure.
Thanks!
Vince
At this point I would suggest you go for server side code. Since you have 30 dinosaurs, it would be much easier to create and maintain a simple page using server side scripts such as PHP or ASP.NET to load the dinosaur from a database.
What are server side scripts?
Server side scripts allow you to dynamically generate a page on the fly whenever the user requests a page. For example, take youtube's search page. Rather than generate a seperate page for every single possible search term, they simply have a base template there, and then they fetch the relevant results based on the search query. The same can be applied to your site. You can have one page for all the dinosaurs, and you would just load the appropriate dinosaur based on the url.
Once you do that, putting the current dinosaur at the top of the page would be a trivial task. Since it appears that you already have a fair amount of knowledge in HTML, it should be easy for you to pick up and use some PHP. Codecademy has some excellent tutorials.
Along the same lines as Kevins answer but more specifically I'd like to recommend you look into a PHP MVC framework such as CakePHP, Laravel or CodeIgniter.
You've done all the hard work manually building these pages, which is awfully time consuming.
Once you learn one of these frameworks and you'll rebuild this site in a day.
If your links had id attributes on them you could scroll the list to a position by linking to #whatever. Here's a quick code example of a link.
<li id="camarasaurus">Camarasaurus</li>
Here's a small example: http://jsbin.com/ExExEvAB/1/edit?html,css,output
As for making it easier to administrate, I'd look into PHP since it's widely available and there's tons of resources to learn from. When you're basically looking for is <?php include "dinosaur-menu.html" ?> since you're thinking in terms of frames. You can make it even easier but this alone should make it a ton easier to update.
I really started to enjoy Mixture recently. It's great for prototyping and is, in my opinion, perfect for exactly what you're trying to do here.
We are designing a web site and have run into some UI challenges that would be neatly solved with a tabbed interface. Users will interact with different elements of the site (there are some basic view/edit/copy/paste functions available) and having only one object in one tab visible at a time simplifies things quite a bit.
We are, of course, completely comfortable with tabbed interfaces but what about novice users? I've searched the web for guidance and I haven't found anything definitive. Do you have experience presenting a tabbed interface to novice users and did they have trouble with it? Or, have we reached the point where everyone is comfortable with tabs and we can use them without reservation?
Usability is important-- more so for this project than most. If naive users are confused by a tabbed interface it just won't work and we'll have to find another way.
In his excellent book "Don't Make Me Think" (Sensible.com), Steve Krug discusses the benefits of using a tabbed interface:
They're self evident
They're hard to miss
They're slick
They suggest a physical space
He goes on to describe the keys to successful tabs as demonstrated by Amazon.com:
They were drawn correctly
They were color coded
There was a tab selected when you enter the site.
Obviously, he provides details to each of these bullet items in the book (I won't plagerize him here). The book is definitely worth a look if you want guidelines for creating web sites for novices and experts alike.
Tabs are becoming common place enough that I wouldn't worry about using them, as long as you implement them correctly. Make sure that you make the active tab visually distinct from the other tabs.
Also, try to create the tabs using progressive enhancement so that the content is still there with JavaScript disabled. There are two main ways of doing this:
Load every tab but the first using
AJAX. The tabs themselves should be
links to the content that the AJAX
fetches.
Keep all of your information on the
page, but hide it using JavaScript.
When you cycle through the tabs,
they are populated from the hidden
parts of the page.
A design resource you might find helpful is the YUI Design Pattern Library and their section on tabs.
I think as long as the tabs are visible as such it's understandable by the user. I have seen websites where they present a vertical bar with links that act like tabs but it's not immediately visible to the user and found that very confusing.
I would have to disagree with those are in favor of tabs. In a design test we did for a fairly high-traffic website (over 1mil uniques at the time), we found that tabs have not been used. Tabs were clearly marked, located to the right of the main content area. Based on that experience I would suggest either finding an alternative or, as staticscan suggested run usability tests to figure out which ones work.
Don't think you can decide a-priori what is usable and what isn't. Do usability testing
"It takes only five users to uncover 80 percent of high-level usability problems" Jakob Nielsen
Google usability testing and start learning. It's not hard.
I tend to agree with lothar and ricebowl - people seem pretty familiar with it these days. The most important thing with any GUI element is clarity - the user must innately know what will happen when they press something (they know that clicking an inactive tab will make it active); and in navigation - it must be very clear exactly which tab they are currently on. As lothar said, if it's not immediately visible to the user, it's very confusing. If you address those issues, then it should be fine.
Just wanted to note SmashingMagazine has a new article showcasing tabs: Showcase of Tabs
I think people are used to the metaphor (from binders, or card-indexes and so forth) of tabs. Especially those that use the web for any length of time. I think that, if IE's adopted a metaphor, it implies a common familiarity with that metaphor.
So, no, I'd suggest that they're not confusing and suggest that you go for it. Just, maybe, post a welcome/first-time introduction (or a prominent 'help' link to such an intro) to the use of the tabs.
I've been a developer for an intranet app that used a tabbed interface, generated with HTML and controlled by JavaScript. This was way before IE7 and Firefox. In fact, it was a bit of a novelty on websites in general, too.
Fortunately, a previous developer had discovered that if you made it look like a dialog box - even down to using a grey background, then people usually understood the metaphor. We also loaded all the content for all the tabs in the initial page-load, and had the Save/Cancel buttons outside the tabbed structure. Because of this, most people immediately understood that they could move between tabs (we used JavaScript to hide and show the DIVs) and a Save would save changes to all of them.
If you want to deviate from such an obvious metaphor, then you need to do some usability studies.
A well implemented Tab interface should not confuse users.
In line with what others have said one of the most ipmortant things to consider with Tabs, or any other navigation interface is for it to be obvious where they currently are in the navigation scheme.
Another important point is not to break the browser! Many AJAX or javascript implemtations break the back button. This is a minor annoyance to some and a major inconvieniece to others. Make sure to consider your target audience here.
Personaly I prefer the oldschool method of not preloading all of the tabs but having each tab as its own page and using a templating methodology to manage the navigation interface, be it tabbled or otherwise. This maintains the browser history and works fine with or without javascipt.
Tabs, etc are just tools. How we decide to lay them out and use them is what determines their effectiveness.
What I try to keep in mind is:
1) Keep it close. The things we use the most should be on the front or up close to the top as much as possible and bury the rest based on how often they are used/adjusted.
2) Easy enough for Mom to use. All interfaces are confusing if they are not laid out in a clear and logical manner.
3) Organize how it's used, not how you think it makes sense.* I often use tabs to break up steps in a process, or to break up areas such as basic / advanced options. I group them based on similarity or usage depending on what works better
4) Keep them few Either way I try to stay below the 7-10 range tops as the human brain has a hard time jumping beyond 7-10 digits, so I assume the same for pieces of information. Vertical Accordians might be something you want to look into as well.
I have also embedded tabs within tabs before. Works well but only one layer deep most of the time.
I imagine there are many of you out there who have developed an application online which automates a lot of processes and saves people at your company time and money.
The question is, what are your experiences with developing that application, having it all set in place, then "spicing" it up with some Ajax, so it makes for a better user experience?
Also, what libraries would you suggest using when adding Ajax to an already-developed web application?
Lastly, what are some common processes you see in web applications that Ajax does well with? For example, auto-populating the search box as you type.
My preferred way of building Ajax-enabled applications is to build it the old-fashioned way where every button, link, etc. posts to the server, and then hijack all those button, link, etc. clicks to the Ajax functionality.
This ensures that my app is down-browser compatible, which is good.
It doesn't really matter which you use, unless you're trying to do something very specialized.
Here's a good list: http://code.google.com/apis/ajaxlibs/.
Yes, auto-completers are a pretty handy implementation of Ajax. It's also quite useful for data-intensive activities like populating drill-down data.
A lot of what you can do with these libraries isn't Ajax-specific, there is a lot of UI interaction that can benefit the user as well. You can do things like slideshows and lightboxes quite easily with many of these libraries.
Pick the one that you're comfortable with. The syntax they all use is a little different. Give a few a spin and try to build simple examples. Stick with the one you like.
Using ASP.NET Ajax to wrap a few chunks of code is an easy way to get going. But personally I prefer to use jQuery. You can easily add some simple Ajax calls with it to make the UI more responsive without the ASP.NET Ajax overhead.
If you are using ASP.NET to write your applications, adding AJAX using ASP.NET AJAX is very straightforward and in many places will not require you to change any code at all except add two controls to the pages you want to modify.
This works using partial page loads. The controls you have to add (off the top off my head) are called something like
<asp:ScriptManager
and
<asp:UpdatePanel
The biggest thing I use for AJAX is lists and search forms. Why? Because the overhead of loading an entire page when you are going though a list of, let's say, 200 records, it will get frustrating for a user to go though everything. However, it is important that if you click on a link in the page and then hit the back button or use a link at the top to return to the same page you were on.
For search forms, as you fill out the form I use AJAX queries to return the first few results and a number indicating how many records that were returned.
For AJAX frameworks, I use mootools. http://www.mootools.net.
Please ignore if not using ASP.NET. Your platform wasn't clear from your question.
Depending on when you created your web application, your web config file may need some tweaks to use ASP.NET Ajax. The easiest way to see is to create a new web site with the ASP.NET Ajax template and compare the web config, copying over configuration items as needed to bring the old one up to date.
If "spicing it up" is all you're after then develop the fully functional app without AJAX first. From here you can unobtrusively add AJAX functionality and ensure that the app degrades well for non JavaScript-enabled browsers.
I've started using jQuery for JavaScript on my site. It takes away all the worry of cross-browser JavaScript differences - things like class and classname, and getElementById. It also includes some very handy and simple functionality for AJAX postbacks. It's very easy to learn and extremely lightweight when used well.
I've seen some good use of AJAX right here on Stack Overflow, things like the tag selector and the question lookup when you type a question title. I think these simple things work best; we're just adding to the user experience with small additions to functionality that are intuitive, we're not flooding the screen with drag/drop handles etc.
I would differ from the first poster. Adding Ajax isn't always as easy as 1,2,3. It really depends on what you are after.
Adding things such as a colour animation can be made fairly easy, but if you are after things such as auto populating a text box, this requires extra code. It's not as easy as adding just something client side. You would also need to add in server-side support to fetch the partial query results.
Going beyond that, it can become even more complex keeping your client-side script in sync with server-side support.
But with the spirit of simplicity in mind there are libraries you can use to 'spice' up a website with animations and other eyecandy that can be implemented fairly easily which have been mentioned already.
I've often had to Ajax-enable an old-fashioned ASP.NET 2.0 sites. The easiest way I've found to do that is to create a new Ajax-enabled site and copy and paste certain sections of the web.config into your old project's web.config.
Just compare the two and see what's missing in your old one. You'll obviously also need to add references to AjaxExtensions and AjaxControlToolkit.