|
Kobayashi posted:So someone else fucks up their implementation and you conclude that you should cripple your implementation by disabling zoom? I don't understand that mentality at all. No, I conclude it's a shitload easier than finding CSS hacks to make the layout perfectly uniform across all browsers, which it probably is for anything non-trivial. Question to you: what am I adding to the UX by leaving this functionality enabled when it's not even supposed to be doing anything?
|
#
?
Oct 28, 2014 19:44
|
|
|
|
| # ? May 9, 2024 21:45 |
|
|
down with slavery posted:If your grandmother can't read 16pt text, chances are she's using her phone's accessibility features, which propagate to the browser. Of course, the accessibility features, such as the ubiquitous and hyper-intuitive pinch-to-zoom which you have disabled in the name of a better user experience.
|
|
#
?
Oct 28, 2014 19:44
|
|
The March Hare posted:Of course, the accessibility features, such as the ubiquitous and hyper-intuitive pinch-to-zoom which you have disabled in the name of a better user experience. Pinch-to-zoom isn't an accessibility feature on the phone, just the browser. Did you ever stop to wonder why you can't pinch to zoom in native apps? There's a very good reason that Android and iOS don't have that feature permeating every aspect of the phone. down with slavery fucked around with this message at 19:49 on Oct 28, 2014 |
|
|
#
?
Oct 28, 2014 19:45
|
|
|
Munkeymon posted:Derp. OK, I'll just paste in from my CSS because the SASS plugin is better at translating than I am: Thanks for this. I couldn't leave well enough alone on this and finally found out the problem. Apparently Select2 (at least the version we have on this app) breaks css menus in iOS. There was never anything wrong with my code.
|
|
#
?
Oct 28, 2014 19:50
|
|
|
down with slavery posted:Yeah, it's an absurd example, but it is a sacrifice in functionality (letting the user's browser determine how to display the content versus defining your own display) that we all agreed was in our best interest however many years ago. I imagine we'll look at browser functions like pinch to zoom (which I still believe only exists because of the need to display websites not optimized for mobile... soon to be archaic) in the same way in the future. Ultimately, it is just a CSS property (you don't need to use the meta tag... eventually) The problem that people are addressing and that you seem to be missing is this: the manner in which you present your content to a user matters far less than how a user wishes to interact with that content. By disabling zooming (which I'm not saying is always wrong) you're implicitly stating that your design being displayed perfectly is more important than a user being able to zoom. You're putting yourself before your user, which is a problem. I'm not going to say you should never, ever disable zooming on a page. There are lots of valid reasons to do so, but the ones you've presented are not good examples. Your job is to allow users to accomplish whatever goal they have when visiting your site in the easiest, most pleasant way possible. By creating "an experience" that neuters an important and often used browser feature you may be failing in that task.* Also, if you've coded your responsive states well it shouldn't matter if the user wants to zoom because the site should hold up just fine. * Of course I don't know any of this for sure since we're debating hypotheticals. e: My point in tl;dr format: just be careful when you do it. It's usually better to err on the side of allowing users more control. kedo fucked around with this message at 19:54 on Oct 28, 2014 |
|
#
?
Oct 28, 2014 19:52
|
|
|
The March Hare posted:Brb y'all letting my grandmother know that she can't zoom on a website because disabling core features of her phone provides a more native experience and that all she has to do is override some settings in her user-agent stylesheet.  What does your grandma do when she can't pinch-to-zoom native apps?
|
|
#
?
Oct 28, 2014 19:54
|
|
|
kiwid posted:
There actually is a zoom feature in iOS's accessibility settings, although the gesture is "double tap with three fingers" instead of pinching.
|
|
#
?
Oct 28, 2014 19:57
|
|
|
Don't disable pinch-to-zoom if you can't be sure you've covered your bases with a responsive design. Otherwise, disable it because your site looks and works like a native app and pinch-to-zoom in native apps doesn't exist and will be loving irritating.
|
|
#
?
Oct 28, 2014 20:00
|
|
kedo posted:I'm not going to say you should never, ever disable zooming on a page. There are lots of valid reasons to do so, but the ones you've presented are not good examples. Your job is to allow users to accomplish whatever goal they have when visiting your site in the easiest, most pleasant way possible. By creating "an experience" that neuters an important and often used browser feature you may be failing in that task.* I'll also say that there are valid types of pages to allow user zooming on as well. Having recently worked on some sites that used the pinch gesture to zoom content without using the built in browser functionality... I admit I'm a bit in that zone right now. But I take issue with the fact that a half second click delay (yes, it's not HUGE, but it's pretty noticeable) and/or using the pinch gesture for other things are bad reasons to do so. I'm not the only one saying those things. Also, I stand by my statement that if a user is pinching to zoom your entire site, your design is at fault 99% of the time and designing/developing around that ability is nigh impossible. A proper responsive design should not require a user to zoom the entire page for any reason. Kobayashi posted:Here's an example from WTF Mobile Web, which is a good Tumblr to follow if you want more examples of well-intentioned implementations that produce This is like the opposite of responsive design, can't believe this is actually a thing that someone thought was a good idea. down with slavery fucked around with this message at 20:04 on Oct 28, 2014 |
|
|
#
?
Oct 28, 2014 20:00
|
|
results.
|
down with slavery posted:A proper responsive design should not require a user to zoom the entire page for any reason. Correct. It also doesn't disable the ability to zoom the entire page, since a user may want to do that.
|
|
#
?
Oct 28, 2014 20:23
|
|
Lumpy posted:Correct. It also doesn't disable the ability to zoom the entire page, since a user may want to do that. Disabling/enabling zooming doesn't really have anything to do with responsive design Here are a few handy links for a beginner to get started: http://en.wikipedia.org/wiki/Responsive_web_design https://developers.google.com/web/fundamentals/layouts/rwd-fundamentals/
|
|
|
#
?
Oct 28, 2014 20:25
|
|
|
down with slavery posted:Disabling/enabling zooming doesn't really have anything to do with responsive design Wow, is there a two drink minimum at this comedy show? 
|
|
#
?
Oct 28, 2014 21:20
|
|
Lumpy posted:Wow, is there a two drink minimum at this comedy show? Sorry your one liner didn't hit home
|
|
|
#
?
Oct 28, 2014 21:21
|
|
|
v1nce posted:stuff This is from a while ago, but thanks v1nce! I'm going to make the dashboard accessible before purchase.
|
|
#
?
Oct 28, 2014 21:44
|
|
|
This line of thinking brought us scrolljacking and sIFR 
|
|
#
?
Oct 28, 2014 21:44
|
|
|
User experience is primarily about expectations. When you're using safari on an iDevice, you expect to be able to zoom. When the user can't zoom they get frustrated/confused.
|
|
#
?
Oct 29, 2014 00:25
|
|
|
obstipator posted:User experience is primarily about expectations. When you're using safari on an iDevice, you expect to be able to zoom. When the user can't zoom they get frustrated/confused. But not if you fool the user into thinking they are in a native app with your ~*expert design sense*~ first.
|
|
#
?
Oct 29, 2014 00:30
|
|
|
I believe the phrase is first-class mobile experience 
|
|
#
?
Oct 29, 2014 04:07
|
|
|
down with slavery posted:Disabling/enabling zooming doesn't really have anything to do with responsive design You'd have to be pretty narrow minded to believe responsive design has nothing to do with accessibility. We respond to screen size, input device, etc, and all with the goal of making our website more accessible to that browser. Turning off user scaling is contra to that goal unless you are kicking goals in every aspect of the accessibility department, and let's be honest, most of us aren't. As an aside, any goon web devs going to the Web Directions conference? I'm a gonna be there, not sure what to expect having never been to a conference of any kind.
|
|
#
?
Oct 29, 2014 08:50
|
|
Maluco Marinero posted:You'd have to be pretty narrow minded to believe responsive design has nothing to do with accessibility. We respond to screen size, input device, etc, and all with the goal of making our website more accessible to that browser. Turning off user scaling is contra to that goal unless you are kicking goals in every aspect of the accessibility department, and let's be honest, most of us aren't. Accessibility is important, but it really has nothing to do with Responsive design. Also, enabling or disabling user zoom does not impact the accessibility of the website in any way so? Words like Responsive Design, Accessibility, they have meanings, and when you just go willy nilly creating your own definitions it makes it difficult to really have a conversation about them. Disabling user zoom is absolutely fine (even better, ideal) if you've built a proper responsive design. If you've got some compelling evidence as to why not feel free to share. Again: 1. Major performance boosts (including a more responsive UI) 2. Ability to use gestures like pinch for other features on the site 3. No accidental zooming when the user double taps something, etc
|
|
|
#
?
Oct 29, 2014 17:47
|
|
|
down with slavery posted:Words like Responsive Design, Accessibility, they have meanings, and when you just go willy nilly creating your own definitions it makes it difficult to really have a conversation about them. Says the guy who trotted out "first class mobile experience" earlier, as if that doesn't mean "a native app."quote:1. Major performance boosts (including a more responsive UI) I watched the video from the timestamp you linked. It looks like you're referring to the 300ms delay that Mobile Safari adds for the double tap to zoom gesture. That's a distinct gesture from pinch to zoom. If you're going to play the semantic dickhead card, then you can't turn around and conflate two separate gestures. quote:2. Ability to use gestures like pinch for other features on the site These "benefits" only make sense if you're developing a SPA or other "webapp-y" interface. If that's your goal, then fair enough, go ahead and fix the viewport. But, that's not normally what is implied by responsive design. Responsive design generally refers to traditional click/reload websites that use media queries and flexible grids to render well on multiple device types.
|
|
#
?
Oct 29, 2014 18:29
|
|
Kobayashi posted:I watched the video from the timestamp you linked. It looks like you're referring to the 300ms delay that Mobile Safari adds for the double tap to zoom gesture. That's a distinct gesture from pinch to zoom. If you're going to play the semantic dickhead card, then you can't turn around and conflate two separate gestures. Disabling user-scaling removes both of the built-in gestures, both pinch and double tap to zoom. So I mean, I can conflate the two when we're talking about removing both gestures. quote:These "benefits" only make sense if you're developing a SPA or other "webapp-y" interface. If that's your goal, then fair enough, go ahead and fix the viewport. But, that's not normally what is implied by responsive design. Responsive design generally refers to traditional click/reload websites that use media queries and flexible grids to render well on multiple device types. No? Do you click links on normal web pages? I'm sorry, the benefits impact any site. I know what Responsive design is, but I don't think it has anything to do with "click/reload" specifically, it's about building websites that adapt to the device they are being displayed on. Really as simple as that. I'm not trying to be a "semantic dickhead" but when you start making claims like "removing mobile browser scaling" flies in the face of Responsive design... well that's just wrong. Kobayashi posted:
It doesn't? Welcome to HTML5? down with slavery fucked around with this message at 18:39 on Oct 29, 2014 |
|
|
#
?
Oct 29, 2014 18:34
|
|
|
Some people getting mad about zooming in this thread.
|
|
#
?
Oct 29, 2014 20:21
|
|
|
gently caress the user, we can all learn something from the way Taco Bell does things: http://www.tacobell.com/ Screenshot: 
kiwid fucked around with this message at 22:06 on Oct 29, 2014 |
|
#
?
Oct 29, 2014 22:01
|
|
|
kiwid posted:gently caress the user, we can all learn something from the way Taco Bell does things: http://www.tacobell.com/ Taco Bell Isn't On The Internet - Except It Is
|
|
#
?
Oct 29, 2014 22:31
|
|
|
I've got a potentially really dumb question, but how do I modify variables up in $rootScope in Angular? I've got a slide-in sidebar that I want to change the content on whenever someone clicks on a thumbnail, and I figured the easiest way to handle where the data in the sidebar comes from/the sidebar visibility would either be in global values, or in $rootScope. I'm trying to keep everything as simple as possible, but I just don't know how to handle modifying global variables. My angular code surrounding this is: code:code:
|
|
#
?
Oct 29, 2014 23:08
|
|
|
I'm in the process of rewriting Awful Yearbook but I'm not sure what to do about the UI. I can code it up just fine if I had a mockup or something to work off of but I feel like anything I design myself is gonna look like poo poo. I don't want it to end up looking like some boring generic bootstrap looking thing that I see on 99% of sites these days. Any advice?
|
|
#
?
Oct 29, 2014 23:37
|
|
|
I don't know if you have zero design instinct I would probably say just get it in bootstrap 3 with all standard bootstrap markup and then you at least have a good base to then either customize the css yourself or look for themes that build off of a bootstrap base.
|
|
#
?
Oct 30, 2014 00:46
|
|
|
I'm developing for an embedded browser and things aren't working very well. I check the user agent and find out it's WebKit 534.34, released May 2011. It also keeps hard crashing running JavaScript.
|
|
#
?
Oct 30, 2014 17:45
|
|
|
Has anybody ever seen an issue where iOS safari renders input type text elements at the wrong size? It's adding about 5px to the actual height, even using !important. EDIT: NM figured it out. It apparently interprets padding differently than every other browser on earth, including OSX Safari. FML
|
|
#
?
Oct 30, 2014 17:58
|
|
|
I want to try to improve a PDF-based workflow by embedding PDFs directly into a webpage, rather than linking out to individual PDFs, as the process currently works. Slapping a PDF into an object tag kind of works, but it it doesn't resize/zoom the PDF to fit (like the browser controls), provide pagination links, or provide a quick way to download the PDF. I'm basically looking for a client-side, in browser version of Slideshare so I don't have to upload stuff to a third party. Mozilla's PDF.js project looks pretty cool, but does anyone else know of anything that might work?
|
|
#
?
Oct 30, 2014 19:51
|
|
|
fletcher posted:I'm in the process of rewriting Awful Yearbook but I'm not sure what to do about the UI. I can code it up just fine if I had a mockup or something to work off of but I feel like anything I design myself is gonna look like poo poo. I don't want it to end up looking like some boring generic bootstrap looking thing that I see on 99% of sites these days. Any advice? Ape the forums' style as much as possible
|
|
#
?
Oct 30, 2014 20:22
|
|
|
Munkeymon posted:Ape the forums' style as much as possible That's pretty much what I did for the original version of AYB, I kinda want it to have a more distinct style. I'm not really sure what I want though.
|
|
#
?
Oct 31, 2014 01:30
|
|
|
I'm getting incrementally better at building my jqueryui sliders, but I've run into a new snag. In this particular slider I want to fix the first handle in place (because its starting value was derived from a previous slider) but let the second handle still be moveable. So like this: I want handle x to be read-only, locked at 300. Slider y’s range will then be 300-to-whatever (2000, in this example). The code below basically says "kill the slider at all values less than 75." But that still lets both sliders increase, which I don't want. I need one that lets me kill the slider on the one handle but not the other, but I don't know how to say it; a way to take the values in that array and kill it for just the first one. http://jsfiddle.net/Jackpot/8fe3rn3f/ pre: $(function() {
$( "#slider-range" ).slider({
range: true,
min: 0,
max: 500,
values: [ 75, 300 ],
slide: function( event, ui ) {
if (ui.value < 75) {
$( "#slider-range" ).slider( "values", 0, 75 )
return false;
}
$( "#amount" ).val( "$" + ui.values[ 0 ] + " - $" + ui.values[ 1 ] );
}
});
$( "#amount" ).val( "$" + $( "#slider-range" ).slider( "values", 0 ) +
" - $" + $( "#slider-range" ).slider( "values", 1 ) );
});
|
|
#
?
Oct 31, 2014 01:57
|
|
|
fletcher posted:That's pretty much what I did for the original version of AYB, I kinda want it to have a more distinct style. I'm not really sure what I want though. I'm a hair interested in collaborating with you on this, I'm currently in a position where when I can design pages I can't put them in my "portfolio" ( really my dribbble ).
|
|
#
?
Oct 31, 2014 02:14
|
|
|
jackpot posted:I'm getting incrementally better at building my jqueryui sliders, but I've run into a new snag. In this particular slider I want to fix the first handle in place (because its starting value was derived from a previous slider) but let the second handle still be moveable. So like this: Do you absolutely need two sliders? http://jsfiddle.net/zLjqmxxu/
|
|
#
?
Oct 31, 2014 02:27
|
|
|
jackpot posted:I'm getting incrementally better at building my jqueryui sliders, but I've run into a new snag. In this particular slider I want to fix the first handle in place (because its starting value was derived from a previous slider) but let the second handle still be moveable. So like this: You can cancel events from the slider you want fixed (see bolded) pre: $(function() {
$( "#slider-range" ).slider({
range: true,
min: 0,
max: 500,
values: [ 75, 300 ],
slide: function( event, ui ) {
if ($(ui.handle).is('#slider-range .ui-slider-handle:first')) {
return false;
}
if (ui.value < 75) {
$( "#slider-range" ).slider( "values", 0, 75 )
return false;
}
$( "#amount" ).val( "$" + ui.values[ 0 ] + " - $" + ui.values[ 1 ] );
}
});
$( "#amount" ).val( "$" + $( "#slider-range" ).slider( "values", 0 ) +
" - $" + $( "#slider-range" ).slider( "values", 1 ) );
});
|
|
#
?
Oct 31, 2014 02:41
|
|
|
The Dave posted:I'm a hair interested in collaborating with you on this, I'm currently in a position where when I can design pages I can't put them in my "portfolio" ( really my dribbble ). That would be dope. Definitely no pressure or anything, I'm in the early stages of development and only working on it a few hours per week as time permits. If you come up with something I'd love to see it!
|
|
#
?
Oct 31, 2014 02:59
|
|
|
Sedro posted:You can cancel events from the slider you want fixed (see bolded)  I was ten miles away from doing something like this, and getting further away every minute. That's simple, and it works, thanks a lot.MasterSlowPoke posted:Do you absolutely need two sliders?
|
|
#
?
Oct 31, 2014 04:17
|
|
|
|
| # ? May 9, 2024 21:45 |
|
|
If I have a text input field with a placeholder called "What's your current location", should I make a matching placeholder value for an option select field, something like "What kind of food did you eat last"? Or should I not give the location a placeholder value, and have "What's your current location" and "What kind of food did you eat last" as labels instead?
Pollyanna fucked around with this message at 21:06 on Nov 1, 2014 |
|
#
?
Nov 1, 2014 21:02
|
|
