I am using a web application that wants to be used full screen. My screen is so wide that the application is nearly unusable full screen. More to the point, the application does deserve that much real estate. I am willing to give it ~1/3 of the width and I do useful work in the other 2/3.
I am convinced that this application uses JavaScript's screen.width to set the size of it's GUI bits. So, I am looking for a way to have my tool (my browser, for example FireFox) return a value of my choosing. Ideally, the same as window.width().
Maybe I would enable such a feature for specific URLs. More likely, I would apply this to everything.
Can this be done as an "extension"? If I need to, I can get the code to FireFox and put the feature I want in there.
What about Chrome?
You can always zoom in with ctrl + scroll. That lowers your window width.
Related
Problem:
I have a small group of roughly 90 users which is extremely important, so when one or two of these business customers desire the UI changed in their web app, they usually get development resources dedicated. However, it's important for us to understand exactly how the application is being used by the group as a whole because this group tends to have strong personal views on how their UI should look and they all use the app differently. I'm having the most trouble with identification of their usage of hardware vs soft keyboard. Optimally I'm looking for an answer as simple as, "use the new Window.TabletMode == true!" I don't think that simple answer exists.
Research:
SO question Detect virtual keyboard vs. hardware keyboard is the only significantly similar question I see but it focuses half of its time on using a JavaScript keyboard to replace the soft keyboard, so the answers talk about how to make the keyboard specific to numbers, dates etc. Additionally, he's looking for cross-browser solutions where I need only IE11+ support. Finally, I can depend on the hardware keyboard being docked and a specific brand (Dell). Finally, I can depend upon Windows/IE11, so there could be other avenues of approach compared to this 3-year-old question. My use of a hybrid tablet also makes the approaches of capability checks useless since I already knwo all the capabilities (touch, etc) are already available on the device.
I could check the Registry for the UI setting, but I really need to stick to JavaScript or something similar.
Android has undocumented but known events which indicate showing and hiding of the keyboard. However, none of the users will be using Android.
IE should receive a WM_SETTINGCHANGE message when the change occurs, but I'm unable to determine if this is made available to a JavaScript API. I'm thinking it would be a message far more specific (if any), so I can't find anything with this search term and JavaScript.
Code:
From W3Schools,
The window.orientation property returns 0 for portrait and 90 or -90 for landscape view.
Combined with window.innerHeight, I could use something like...
var portrait;
$(window).on("orientationchange",function(event){
if (event.orientation == 0)
{
portrait = true;
}
else //if not, it's landscape
{
portrait = false;
}
});
Then I would use window.innerHeight in combination with the value of portrait to determine if the width to height ratio looks like I have a keyboard open. This approach really might work in fullscreen considering my fairly narrow constraints, but what if the browser isn't fullscreen? I'm sure there are plenty of other reasons to not write a hacky ratio calculation for this. Additionally, my greatest desire would, of course, be to do this with any browser and any screen size.
These things I can handle: I'd need to set variables on the loading of the document and work out a way to determine when the typing becomes relevant. I might need to check for some browser capabilities. Perhaps I'd increment counters for typing with and without a hardware keyboard. Once I hit a certain number (let's say 5 keystrokes), I'd send a POST request to my data tracking endpoint to let it know that session 12345 used the soft keyboard (or hard keyboard). Afterwards, I'd unsubscribe from the event handler. However I work this part is of less concern because I don't think I'll get stuck on anything, but I didn't want anyone to spend time on beautification or development of a huge example.
Environment:
Hardware should all be Dell tablet/laptop hybrids (specific model TBD) with IE11+. I hate to make something IE specific, but if it runs on IE11+, it's totally acceptable.
I should be able to pull in any sort of JavaScript libraries suggested, but keep in mind that JQuery 2.2 and Knockout 2.1 are already present, so little "weight" is added for a solution with JQuery usage.
I probably can't get approval to write an application that uses ActiveX or some other heavy handed customized approach that would require installation of a local application because my company has roughly 50,000 users, and a deployment like that for 90 users would be overly complex to maintain.
The screen sizes should all be 11 inches, but I'd be sad to resort to using specific size and resolution because an answer like that would be extremely limited in application for me or future readers.
Impact for Readers:
I'm seeing a move away from Ipads in the medical kiosk / EMR space because Ipads limit a lot of the UI choices in favor of a cohesive experience. Physicians especially will often get attention of high ranking IT leaders if they desire a very specific UI change. Microsoft has tended to allow a lot of non-standard intervention and (more recently) more standard types of intervention in how the browser works. I think a lot of this movement is going to Windows tablets for this reason and also for the reason that many medical groups are heavy on .NET development capability.
Bottom Line: You can't get exactly what you want. With IE11 you actually have a couple other challenges. You can't simply use the Fullscreen API with promise = element.requestFullscreen() because IE will request permission from the user first, and the API lets you check for capability but not state. Also, multiple fullscreen applications can share the desktop in Windows 8 and 8.1, which is a bit counterintuitive.
However, if you can count on the web app probably being fullscreen, your "hackish" JavaScript solution probably is the best answer. Get the initial dimensions when the document loads and compare during key presses. As a side note, keep in mind that the user might not be using the software keypad just because he or she isn't in the dock. The user still needs to explicitly open the software keyboard.
If you had said "Android only", it would be an easy solution, but you already demonstrated you knew that in your question. If you wanted to use a desktop app, there is some MSDN documentation on a hardware token here but again you specified that this wouldn't be simple enough.
I have the standard "responsive image serving" problem, but with some complex twists. I expect I'll need to build my own solution to the below, but it's a few months down the line so I thought I'd bring this by the community now for help with my approach and getting started. I also think the solution I'm looking for would have pretty wide appeal, so this could be valuable to the community as a whole.
The problem:
We'd like to provide users with images, embedded videos, etc (anything that takes a lot of time/bandwidth to load and takes less when lower res) but change the loaded dimensions depending on the size the element is actually allocated on the page. This is basic "responsive image serving" applied to a few other types of assets (though since we provide lower-bandwidth file versions to mobile devices, I think this also falls under "adaptive design"). But don't worry about other types of content for now, let's focus on images.
We need to determine the appropriate max-width for a each specific asset placement, for each screen width breakpoint, without providing this info as configuration.
I'm creating a platform that will serve pages relying on HTML templates from many different parties. Images can be served from anywhere on the page, and pages can use any styling system they want, so we have no idea what the appropriate size for an image is just by looking at screen width. We need to actually evaluate the max width of the placement at each supported sizing breakpoint. Sure, this could be done manually in advance given a design template, but let's assume that's too much work for these 3rd parties.
For example, in Twitter Bootstrap 3 an image contained in a col-md-8 should be at most 720px width when browser width is < 768, but if it was in a col-sm-8 it should be smaller than 470px. And if we're using a different framework altogether these would clearly be different too. I need solution that can take into account everything the CSS is doing automatically, because I have no idea what the CSS will do.
We can't do any processing during the image request. We rely on a CDN (Cloudfront). They are not going to implement our custom code on each of their edge locations, and I don't want a visitor in New Delhi or Berlin to have to send yet another request halfway around the globe, for every sized asset, before they know what the final url is. So that rules out solutions like this controller-based solution and the PHP adaptive-images script.
We need this to be fast. There's a good amount of wiggle-room on the server side, since caching is so easy and flexible with Rails 3 & 4. But we probably can't use jQuery.width() on every element for performance reasons. After all, the entire reason we're serving responsive images is to decrease perceived page load time. But we do have access to jQuery in general, and we could probably load up Modernizr all the time if we needed to (currently only included for low IE with conditional HTML).
We don't trust User-Agent headers enough to base our browser width on them. I love the idea behind mobvious 1, 2 and its friend responsive-images, but there are SO many versions of browsers on SO many different devices out there. How complex would it be to build a truly reliable system to determine browser width on this, as opposed to directly calculating it using JS?
Clients without javascript (and thus crawlers) will need access to an image. Easiest solution here seems to be to include a <noscript>....</noscript> with the canonical, largest version of the image inside.
The solution
It seems like the only way to do this is to:
Have the server pass all the available sizes, then calculate the width of each element on the client side using jQuery in some performance-efficient way (maybe using $.css_width() or some sort of specialized script). So server would create:
<span data-respv-img-id="picture_of_unicorns"></span>
<noscript data-respv-img-id="picture_of_unicorns" data-img-720- url="//cdn.example.com/assets/picture_of_unicorns_720x480" data-img-320-url="//cdn.example.com/assets/picture_of_unicorns_320x260" data-img-120-url="//cdn.example.com/assets/picture_of_unicorns_120x80">
<img src="//cdn.example.com/assets/picture_of_unicorns_720x480" alt="Magical unicorns">
</noscript>
And if we're on a small screen and only the 120 fits, the JS would turn this into:
<span data-respv-img-id="picture_of_unicorns">
<img src="//cdn.example.com/assets/picture_of_unicorns_120x80" alt="Magical unicorns">
</span>
OR have the server do some sort of pre-processing, so it knows exactly what size image fits each placement on each browser width, and delivers:
<span data-respv-img-id="picture_of_unicorns"></span>
<noscript data-respv-img-id="picture_of_unicorns" data-img-1200- url="//cdn.example.com/assets/picture_of_unicorns_720x480" data-img-1024-url="//cdn.example.com/assets/picture_of_unicorns_320x260" data-img-768-url="//cdn.example.com/assets/picture_of_unicorns_120x80">
<img src="//cdn.example.com/assets/picture_of_unicorns_720x480" alt="Magical unicorns">
</noscript>
And we end up with the same thing as the other approach. But this time jQuery's job was much easier, as we passed all the sizing work off to the server. But this requires loading up a full browser stack on the server side to generate each request. That's ok with caching, but sure does bring a lot of complexity along.
Note that both of these solutions would allow for scroll-based image loading, which is another aspect I'll need to implement, but not something we need to discuss now.
Long story short: Which approach would you recommend? Can you think of a better way?
my site looks fine untill people start zooming in and out and after hours of work on it and messing with its css I am clueless on how to fix this zoom problem. Should I somehow fix the zoom to a certain level? if so, how can I do it? I tried fixing this zoom issue but putting everything into a table but that isnt really working so I dont know what to do..help..
This is how it looks on safari, its fixed if i adjust my zoom level but initially looks like this:
Then on firefox and chrome looks perfect:
The zoom level of the browser is something that is strictly the domain of the user - it is bad practice to interfere with user-level choices such as page zoom, and usually you are technically unable to do so anyway. A user will zoom a webpage because they wanted to enlarge it, the reasons are their own and an individual site should not (and can not) interfere with that choice.
Instead of fighting the user, you should seek to design your site in such a way so as to make the content the most important thing. You should craft your design in such a way so that when a user zooms (or makes other changes like disabling CSS or Javascript), the content (presumably the point of having a website at all) is the focus.
Using percentages for your layout, using em for font sizes, and other such techniques will increase the accessibility of your site. See articles like http://24ways.org/2007/css-for-accessibility or http://www.w3.org/TR/WCAG10-CSS-TECHS/ for information on using accessible web design techniques.
EDIT
The screenshots demonstrate one of the many pitfalls in trying to prevent accessibility support - different browsers implement zoom in different ways. Some only increase the font size, some enlarge the images, it is not consistent. The trick is to make it not matter, not to prevent it from happening.
Here's an IE fix
http://www.bennadel.com/blog/1354-The-Power-Of-ZOOM-Fixing-CSS-Issues-In-Internet-Explorer.htm
.css
{
zoom: 1
}
Short answer: No, You cannot modify the end user's browser setting for zoom level.
Maybe you should look into CSS patterns for designing sites that zoom nicely. For example I beleive em's zoom better than point based font sizes. etc
take a look at articles like these: http://kyleschaeffer.com/best-practices/css-font-size-em-vs-px-vs-pt-vs/
Also, if you post specific problems we may be able to help solve them on a one off basis
I have this site which was developed few years back. At that time it was developed keeping 1024x768 resolution in mind. Now a days people use much higher resolution.
I was thinking if it is possible to open the site zoomed in automatically if the resolution of user's monitor is set considerably higher than 1024x768?
Right now if I look my site on my macbook it looks like following:
I would like it to be opened up like following:
I hope I have explained the question correctly.
My browser settings are my own! It's none of the webeveloper's business to change anything in that area!
What you may be looking for however, are flexible layouts. (But that doesn't work well when you integrate pictures, as with zooming, they tend to get pixelated...)
Update
If you want to have a flexible layout that scales well and easily (also through scripting), you can consider using the em unit.
To have only a layout adjust to the screen width for instnace, you can also use percentage values.
I would like to programmaticaly determine the DPI of a user's display in order to show a web page at a precise number of units (centimeters/inches). I know it a weird request: it's for a visualization research project and it's kind of a control. We currently do it by having the user place a credit card to the screen and match a resizable div (via Mootools) to the real credit card, and voila we can get the DPI and display the page correctly.
Can anyone think of a programmatic way to do this?
If you're doing this in javascript/mootools, CSS units are your friend. You can specify sizes in inches or centimeters, or even points (1/72 of an inch). If you absolutely need DPI for whatever reason even though you can specify sizes in those units, simply size the "resizable" div you are using to a known size and calculate from the translated pixel size.
Edit:
Unfortunately, the CSS units of
points, cm, and in are not physically
correct. They are only relatively
correct. This was the first thing I
tried until I realized it wasn't
working and checked the CSS spec.. to
my dismay. – Brandon Pelfrey
That's a good point; browsers tend to fake it by assuming a default DPI (I think 72 or 96) and going with that.
Well, if you need precision sizing like you're asking for, you're out of luck. You'll never be able to get it without being able to read both the current resolution of the monitor the browser is on and the "viewable screen area" of that monitor. Ain't no way you're gonna get that via Javascript.
I suggest that you make the default assumption that browsers do and size according to the CSS units. You can then allow your users to "adjust the sizing" using the method you mentioned, but only if it's necessary. Do this with on a separate page with the DPI calculation stored as part of the users session or as a cookie.
Alternatively, once Microsoft fixes this bug, you could use Silverlight's "device independent units" for accurate scaling.
You can't. DPI is a function of the pixel resolution of the screen and the physical dimensions of the display. The latter is not available in any browser interface I am aware of.
I think that you won't get precise results - for example you can resize the picture using the monitor. I'd rather stick with the user-driven method, although you can f.e. detect screen resolution for a first estimate.
It's not possible from a browser without code running on the target computer. If you could install something on the target computer you might be able to determine enough about the monitor to calculate this.