Im currently working on a mobile web app and am wondering if I should use individual images or continue with using image sprites like I would for my desktop site? Im just worried about the increased file size from combining all the images and how this could have an effect on the load time of my pages?
Kyle
I don't see anything wrong with using a sprite set, just bear in mind that if you target the app for iPhones, they will only cache files under 25kB in size. So, if your image grows too much, it would, paradoxically, be a better idea to split it into separate images. This will account for more HTTP requests on the first run of the app - but will not generate the additional HTTP request continuously with each subsequent page load, saving both your and the iPhone user's bandwidth :). Oh, same applies for JavaScript and CSS files :).
Sprites work just fine on the vast majority of phones (barring older Nokia Series 40, BlackBerry pre v. 6.0 and any legacy devices (anything without a full HTML 4.01 browser).
What you should be aware of is that if you are using a flexible/responsive layout with primarily flexible units, it can be very hard to properly position the sprites while retaining the flexibility in the layout.
Related
On this page, the images look fine on desktop but are white/not found on mobile devices. I have no idea why this is happening. I'm just calling an img tag but it says its not found on mobile even though it is there
I have checked your files, #MrVimes is correct your should finish your html which will help validate better on slower devices.
However the problem is purely down to size of the image. Chrome Dev tools shows me that they are massive in size, Enable emulator and select iPhone 5 and see what happens. It is just taking a long time to download.
Try using Picturefil.js to serve smaller images or make them smaller in your software application.
This was the picture I got from Google Dev Tools (which is free and amazing):
Also I noticed that your need to change the way the images are handled in CSS, if you open dev tools:
Position:center
Is not valid, maybe set it to relative or static depending on how you want your page structure to look.
I also saw you may want to update your header with this css:
z-index: 99999;
This will make your header appear on top, as the z-index changes the layers of the html elements (much like the fillings in a sandwhich)
sorry my friend but this is false COMPRESSSING THE IMAGES TO 50KB the big images won't appear because your cache browser is full you have to empty your history/cookies/cache of the browser
IOS DEVICE SUPPORT 32 MEGAPIXEL SIZE OF IMAGE IN SAFARI
take a look here for maximum image size and resolution support Apple IOS developper
to delete your cache just go to "Setting=>Safari=>Cleare cache=>clear cache" and that's it
Note: Check the avaible space on your IOS DEVICE should be greater then 50MB
You have to Enjoy the technologie by let the images greater then 1.5mb and works in both of computers/devices
So I've just gotten my app to work on IE10/WP8 (demo here), and one thing I've noticed is that both scrolling and transitioning between carousel cards are reasonably sluggish on Windows Phone. Specifically, it takes like half a second for the screen to catch up to my finger. I'd say it's at about 80% of the responsiveness than I get from Android and iPhone, which both have pretty much perfect responsiveness. For reference, here are the devices I'm testing with:
iPhone 4
Android Kyocera Rise
WP8 Nokia Lumia 920
Desktop PC (Windows 8)
So among the phones, my Windows Phone is easily the most powerful, so it likely isn't just a hardware consideration. I've found this sluggishness in fastbook (http://fb.html5isready.com) as well. However, the sluggishness on either app does not exist on my Windows 8 PC.
Is there a particular consideration that needs to be taken with this part of performance in WP8? I've done quite a lot of work optimizing overall performance on the app (destroying/recycling all unused DOM elements, event delegation, etc) and the rest of the app runs quite well. So I'm not sure where I should go from here.
Thanks in advance!
How are you serving those large images? Have you tried using sencha.io to serve them? You can also use the yahoo tool smush.it to crush images further without loss of quality.
Another question: are you using CSS shadows and effects? These can have a noticeable performance hit sometimes...
Also the custom font, how are you implementing that? Google fonts work well, or are you implementing it another way?
:-)
My apologies for a more "theoretical" question, though I suppose this is more of a "state-of-the-industry" question: I'm curious about the options available for building a website meant to target multiple platforms (desktop browsers + touchscreen devices, like tablets and smartphones).
Technologies like CSS3 Media Queries give us the ability to format our content based on screen size (among other things), which is great - but what about other functionality? For instance, touch events - these can still get very sticky depending on what device you're targeting, etc. So is it possible to build one site to target all of these platforms? Or is it still necessary/better to use device detection scripts to redirect to versions of the site meant for touchscreens (Apple-devices or otherwise)? Or perhaps, does it depend on what you want to do? Is there a line drawn that, once crossed, would require a separate version of a site to be made? Anyone care to share their experiences?
It all depends on how complex your website features will and and how they differentiate from the offline or online version.
Sometimes it's better to make a totally different version of your website and redirect to it, sometimes, a few touchevents calls on the page will not make any different for desktop users, while mobile will see something different.
One good case to look at is the WP-Touch plugin for Wordpress. While you have a version of wordpress for regular browsers, it tweaks PHP into delivering a totally different and mobile experience for the mobile user.
If you have the patience, resources and time to make a proper mobile website from your regular one, do it! If you don't, a different stylesheet and some touch events properly coded can seal the deal
I am considering a project in which workstations, connected to a central server display various content under the control of a central timeline.
Requirements are that the kiosks could have various compositions of monitor and an extended desktop. This screen space would be use to display images, movies or various mosaics of images and movies.
For example, a machine with 3x3 monitors might be configured to display video in the lowest right four screens, a title on the top three videos and whatnot elsewhere.
I am figuring out how to create the viewer. I think that sticking to web technologies I know well would be good and using JavaScript for the timeline engine sounds easy.
As for codecs and video drivers I think I would stick with Chrome, Css3 and Html5, I think I can require Chrome and Windows 7.
There are a few concerns, though.
Will there be performance problems considering video split on different monitors on an extended desktop?
Will it be pixel predictable to size and stack divs so that images fit inside a physical monitor or monitor group?
Thank you all.
A great solution for this is Adobe AIR. You are already talking about HTML, might as well check that out.
The nice thing is that AIR provides facilities for kiosks. Check out this link:
http://www.adobe.com/devnet/flex/articles/flex_kiosk.html
Just replace everything there that says Flex with HTML/Javascript. The platform functionality is available to both technologies.
As for stretching a browser or AIR app across multiple screens, I believe you would have to manually position the window yourself. I.e., if you maximize an app window on a multi-monitor setup, it expands to the size of the monitor only, not the entire viewable area. You likely will have to manually position/resize in Javascript.
As for using Chrome as a client, see this thread:
http://www.google.com/support/forum/p/Chrome/thread?tid=12bde481a208c4ca&hl=en
It doesn't look like Chrome supports a kiosk mode.
Browser shouldn't be a problem at all. Just remember the architecture - you'll need a server somewhere and each kiosk will be a client. Just set up a port/url for your app and there you go. Chrome has some features that allow you to prevent users from exiting the app. I forget the specifics, I believe it involves incognito mode and something
Company I work for does something a lot like this. We make 'apps' that run on iPad and another touch screen device called MSI (btw - one of the advantages here is the freedom of using different client platforms), but not in the typical Objective-C way. Theres a server with a LAMP stack and the client uses the browser.
Will there be performance problems considering video split on different monitors on an extended desktop?
I think more than multiple monitors what you really have is multiple clients. This is interactive to some degree right?
Will it be pixel predictable to size and stack divs so that images fit inside a physical monitor or monitor group?
Yes. I don't really do artsy design and display details so I can't comment on specifics. But I don't think this is too hard - especially if all the clients are similar. Majority of this would be dictated by CSS.
EDIT - took a look a what we do on chrome. between running on start up, using kiosk mode and incognito (both can be runtime flags) and the regular F11 kind of full screen, you should be pretty much there
Will there be performance problems considering video split on different monitors on an extended desktop?
IMHO screen space does take a little toll on your video processing. You will need a relatively good video card to support such huge amount of displays. I am a user of dual screen on ATI Radeon HD 5750 (1GB), and I can do intense gaming on my main screen while read news and be on twitter on my other screen.
Will it be pixel predictable to size and stack divs so that images fit inside a physical monitor or monitor group?
DIVs can be easily styled and positioned using CSS. You can define the number of pixels for both width and height. And if you do your storyboarding and layout design, everything should fit in your window.
However the trouble for you is that I assume you're stretching the browser window across the 3x3 screen. I recommend you to instead have one browser window per display.
I've tried that Chrome can full screen on each display without exiting-full-screen-mode on the others.
I used this method: CSS Throwdown - Preload Images without JavaScript
By Jeff Starr - http://perishablepress.com/press/2007/07/22/css-throwdown-preload-images-without-javascript/
It works fine when I view it in web browser, however on mobile, it doesn't seem to have any effect, .png icons still takes too long to load.
Preloading doesn't make everything magically faster - it just means that requests are sometimes issued before the data is required. Is the preloading happening at all? Perhaps things are just slow because the mobile connection isn't great.
That method of preloading images looks to me like it'll work fine on mobile browsers - I highly doubt mobile browsers "optimise" by not fetching images are not visible.
If the mobile browser doesn't support javascript (or support javascript well enough) then preloading that way may not work.
I expect it's also unlikley that preloading with javascript would work on any browser or proxy which uses transcoding or pre-rending on the server.
Have you tried the old school (90's) approach to preloading which was to include the image on the homepage (or even each page) but sized to 1px by 1px (could also maybe try 0x0).
This could mean that the user is paying to download more content than they need. Which is an issue to consider.
First thing to do is: make sure you really need the image; make it as small as possible (physical size & image encoding compression); and [gzip] compress the file as it's sent over HTTP. Also make sure that you're doing everything you can to allow the user/client browser to correctly cache the images.
If your site is going to be aimed at mobiles, and not just the one you are testing with, you might have difficulty in finding a universal solution that works across all mobile browsers. If you want to improve the download time of the image, maybe you could consider adjusting the compression of the image to reduce the size?