I am in the process of building a site with a large amoutn of divs, perhaps 300-1,000. Each are small, 100x100, and when the user clicks on each div a small modal pops up w/ basic info about each div, maybe 2-3 paragraphs and some images; all this works great. However, I fear as the divs increase in quantity, this amount of images/texts that are loaded will slow down the site to a crawl, resulting in a terrible ux; it's also aesthetically dispeasing to me (and I'm sure to other coders) to have so much code on a single page. So the question is thus: what is the best way to make modals that load quickly, but don't slow down the site, or are there alternatives to them?
I thought about imbedding the modal content (text,images) inside CSS, and perhaps makig it between 2-5 css files?
I thought about pop-ups, but those are problematic, as some browsers won't respond to the specific size dimensions of a pop-up, (IE), and some block pop-ups all together.
Has anyone else dealt w/ this or has an interesting solution?
I appreciate everyones help.
Related
I have a long job application form, about 7000px in length, with several tables that contain form inputs (textboxes, radio buttons, etc.). Each table is nested in its own div (applicant info, work history, education etc.). I intend to make the sections collapsible when complete, however design view started overlapping the elements after about 5000px, making it hard to judge the layout. At runtime no overlap occurs. I realize design view is not an exact browser representation, but this overlapping seems exceptionally quirky. I am only using relative positioning and minimal styling at this point. I tried setting the height of the content to a large number to no effect. Does anyone know if this is a bug with VS or if there is some setting that will prevent it, I couldn't find any. It seems to only happen when the content of the page runs long. Thanks.
I have recently taken control of a large website. My problem is that sometimes, on some browsers/ computers, when you navigate between pages (or hit refresh) the entire content loads slightly to the right, then half a second later, jumps back to the left where it should be. The distance is only around 5mm, over the course of a second, but it is noticeable.
Things that are useful to know:
It is a wordpress site, but has only basic functions- The menu contains jQuery but there's little other javascript to prevent loading.
All content is wrapped within a container that is centred using
{margin: 0 auto;}
There are several CSS style sheets, and some major tags such as the container have been defined several times- i even found a discrepancy between the width between two of these, but when fixed everything still jumps.
There are no images on the side that are causing it to jump by being slow to load.
The content only jumps if the content is greater than the screen height- that is, it goes off screen.
Content will jump with my old computer, but will not jump with my new computer, on the same network and connection.
On an older computer content will jump with IE 10, but not when you put IE10 into compatibility mode.
I'm afraid that i don't have the permission to put a link to the website, so i've tried to put everything i know about it here. I know that makes it more difficult, but any pointers to put me in the right direction will help a lot!
Update!
The scroll bars were the problem- I used the answer from this thread: Making the main scrollbar always visible
and all jumping has stopped!
You should simplify the problem removing 'things' until you isolate it.
If you don't have a preproduction or development environment to test make a copy of the page where the problem still exists. Then start removing things. If any div needs some content so the layout is stable replace anything dynamic or complex with simple text or images.
If the problem seems fixed removing something don't think you got it, undo what you just did so it still fails and keep on removing parts or functions that definitely have nothing to do with the problem.
When you have a minimal example that is still failing it will be much easier to figure out what the problem is or if not post the example here so we can help.
I have been tasked with optimizing a marketing landing page for speed. It already does really well, but the problem is its very graphic heavy.
The entire thing I would guestimate is 30+ pages long all on one page (It must be like this, and everything must be images due to conversion reasons).
Here's what I've done so far but I'm not sure if there's something else I'm missing
I re-compressed over a 140 jpg's on the page to slightly smaller sizes
I played around with sprites but most of the images are all large (like entire testimonial boxes that are 600px wide). The sprite images ended up being like 2mb. That page actually took longer to load for some reason (by almost 2s) so I took them off
The MOST important thing is that everything immediately at the top loads as fast as humanly possible and before anything else so that the sale isn't lost by someone starting at a bunch of images loading out of order. I used some preaching images with this method: http://perishablepress.com/press/2009/01/18/css-image-caching/ - It did seem to work quite well on the smaller images, but when I add the background (which is very graphic intensive) everything seems to slow down at once, like its trying to do a certain number (5?) of images at a time. Ideally I'd love to group the first 4 smaller images being pre-cached, and then follow it up with focusing all bandwidth on the background, then the rest of the entire page in standard order..
Google Page Speed score is 90/100. the only thing its concerned about is unused styles but that I'm not really concerned about because its about 2kb total... the overhead from the 7mb of images is way more important.
I have the option to use a CDN for the images but I'm not sure how I'd go about doing this or if it would actually help?
I feel I've done all I can but then again I could totally be missing something...
A CDN would definitely help. And with 140 pictures, I hope it
contains more than just server. Just link directly to the IP of
the servers, to avoid unnecessary DNS lookup.
Minimize HTTP requests. You mention that you've been experimenting
with sprites. I still believe sprites to be the way to go, but you
might not want to create just one, huge image. If you have 140
images, you should probably have about 10 sprites.
Make sure that you have set headers to make the client cache all
content. Remember ETags.
Gzip/compress content for browsers that allow it.
If the source code is lengthy, make sure to flush the buffer early.
Consider lazily loading images below the fold? There are a number of javascript plugins to accomplish this
scrolling pagination + combining images as sprites on a per-page basis.
I'm working on a new web site that currently is configured as a full height (that is, 100% available browser window) application. In terms of layout, it is something like this - http://stevesanderson.github.com/fixed-height-layouts-demo/pane-transitions-tablet.html.
Our web site does nothing with the actual browser window size, like switch browser into full screen mode. It only uses the available space.
Operationally, this is going to be a semi-internal data entry application. Almost all pages are data entry forms or summary pages
Personally, I think makes a very nice looking app. However, some of the other developers are comparing this design with content in scrollable tags to be the same as iFrames. And as such should be avoided.
Is there any background / best practices information about designing a web site this way?
I personally love sites that choose to do this; I think that it's a great way to use up the available real-estate that you have. My one piece of advice would be to add a min-width and a min-height to your page so that you don't have to worry about your site breaking if the browser gets too small. This will not only improve the overall user experience, but will also prevent future headaches when trying to get your design to work in obscure dimensions.
It looks fine, and at first looks more like a 'real' app. The only weirdness with this sort of thing is that on OSX you get a bit of a bouncy effect when you hit the top and bottom because of the rubberbanding on the scroll. If you aren't sure what I mean, grab an iPhone/iPad/Mac and scroll up and down past the top or bottom of the content.
In reality it shouldn't be too hard to enable or disable this feature, so why not start with it, then revaluate once you have gotten going.
There aren't any good practices or background information that I know of on this subject. Just follow the normal rules of thumb, if it looks good, is light and loads well, and it is usable, why not?
When designing my homepage, I feel like the common knowledge is that it is bad to just have one big picture in the center that gives all of the content. The "right" way to do it would be to chop up the large layed out image into several small backgrounds and make the text use standard html with css background images for layout.
Is the only reason one big image is bad SEO reasons?
A search engine can't make sense of it.
A blind or otherwise visually-impaired person can't make sense of it.
Someone blocking images because he's on a mobile phone with expensive internet can't make sense of it.
There are a few reasons :-)
Also important:
Changes are not easily made to whole, pre-composited images, unless you still have access to the original layered variants. And hopefully they contain text as well, not just pixel data. (Mentioned by others before already. Credits go to pierre and Kendrick)
If you're using background images don't forget to set a text and background color too. Otherwise people not seeing any images might have a hard time deciphering your text (black on black isn't nice to read :-))
You can still use one large image as background. How the text is layed out above that is another matter entirely. In fact, chopping up the image and piecing the pieces together is painful using CSS too. In my experience it's best and easiest to leave background images unchopped and instead composite the rest of the layout above them, using other images or backgrounds if needed. This gives you a little more flexibility when changing a layout again, too.
SEO is one. Handicapped accessibility is another big one -- a screen reader can't read text within an image, typically. Page load time is another one; a user with a slow connection won't see anything useful while the image loads. Lastly, many browsers will use multiple connections to request resources such as images, so they can be loaded simultaneously. If there's just one image, only one connection can be used.
Updating will be tedious; you can also no longer rely on many benefits of CSS.
It's also bad for accessibility (screen readers, text-resizing, different monitor sizes)
It also removes your ability to easily edit text content.
I certainly wouldn't do it if you're looking for a web-developer job, but if you really don't care about the above, you won't be the first person to do it...
I see no reason at all in using imagea to represent something what can easily be achieved with HTML and CSS.
You're putting up a web site to enable communication between you and your visitors. Images and Flash prevent that.
Generally, you design a site with HTML/CSS and text. Only when you wish to add some design that cannot be expressed with standard means, then you use images. But have your site degrade gracefully for those who cannot or does not wish to see images. Let images be an addition, like an advanced version, in no case a replacement for text.