So i got a job to make our desktop notification more noticeable. I'm already using sound on display but some users, wants a bigger visual notification. I have no idea how to make notification larger, or how to make it blink or something like that or maybe change background color.
Here is code that i use at the moment
if (window.webkitNotifications.checkPermission() != 0)setAllowNotification();
n = window.webkitNotifications.createNotification('link/to/image.png', 'Warning!', 'Hey u got new important message');
n.ondisplay=playSound();
n.show();
It's used for admin of site so they know when user's do something, so it will not be used as spam for normal users.
Btw: There is no tag desktop-notifications.
The notifications as provided by the browser are mostly out of your control as far as the extend they attract attention. Why? Because as you pointed out it could otherwise be misused (despite the fact the user has to give explicit permission for it). If you users want more attention attracting notifications the most valid way would be to show them in your own webpage, of course that also means that the user has to be on your webpage, but if that's where their focus lies then that should be fine. (And otherwise subtle desktop notifications are correct in being subtle, as they should distract too much from what the user is doing).
Related
I just read this article that talks about how email clients clip emails that are over a certain size and sometimes even marks them as spam.
Since images are included in most emails using a <img src="https://www.files/my-image.png">, would these images be included in the size calculation? They're loaded asynchronously so I'm confused if they would be or not.
It all depends on the mail service provider. The type of message that you are sending and the recipient - and of course you don't always know the answer! You can embed, you can encode and you can include links to images. It's impossible to expect everyone to get the emails you want to send!
For instance HTML emails. Who would know if the email you send will survive the process? There is so much that could go wrong.
When using images in an email I try to go for one picture and a logo as a max, with the text set up to appear early on and to get to the point. If I have a long message, I will want to tease it on the email, get the click and have my recipient come to a landing page where I have much more space and much tighter control.
This I find increases my open rates etc, most importantly, it tends to be the way that gets the most people to take action. I do like to use styled HTML. This means that the emails look good yet the focus is on the text so if the style does not survive the transmission, the message still gets through.
You have some choices!
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.
I'm using a facebook like chat called envolve for my site. It works great, except that it changes the some layout properties of my site, specifically the size of some font and links, and the font background in pre tags that are embedded in a custom "lesson" class ()
I was on their site where i asked about it and a couple other people mentioned they have some similar problems but didn't know how to fix it. I contacted their support and after about a week they sent me an email about how they don't have enough resources to look further into the problem, which is understandable since i can't even figure it out ;)
I'm just asking here in case someone might have an answer to this.
To see how the background of the font inside pre tags change when the chat is enabled, go here:
http://braynzarsoft.net/index.php?p=D3D11OBJMODEL
You will have to log in to enable the chat and see the change. Log in with:
username: guest
password: pass
First look at the page without being logged in, then look at it logged in to see the difference. I'm really out of ideas, so i hope someone here might be able to shed some light on this
EDIT: i should mention to enable envolve on my site, i only need a single line in php, which connects to the envolve server, so there's really not much i can do with the files they provide to enable the service. There's one file that comes with it, called envolve_api_client.php, but all this file does is connect to their server
I would do the following:
Make sure all your styling is in stylesheet(s).
Remove your stylesheet.
Confirm that their part looks ok.
Start adding yuor styles back in, one by one (or in groups) and seeing what conflicts.
Decide what you want to keep and what you want to add.
Part of my job involves turning psd designs into html to be emailed out for email campaigns. In the past I've always gone through and converted everything to a suitable html element where possible but I'm now questioning whether there's any point to it?
Is okay just to use one giant image? I only ask because it seems using html elements is only really important if a) I want the information in the email to get to the client if images are blocked and b) for SEO.. yet search engines won't be indexing my code since it's all going through email.
If I'm pretty confident that the clients I'll be mailing won't have the images blocked, is it okay just to treat the entire email body as an <img />?
Thanks
I guess it would be okay, but I wouldn't recommend it. Here are a few reasons why:
The readers won't be able to select and copy any of the content in the email, which in my opinion is really annoying.
You will not be able to have links in your email, the only thing you can link is the entire image.
If they do have images disabled, which i believe is fairly common, the wouldn't see a thing without downloading the image.
Increased email size due to the large image, which for mobile devices is a pain.
An image will not adapt to the window/display size. Text/HTML-based mails can at least break row if the content doesn't fit, to make it more readable.
And the list goes on. The other answers point out a number of additional reasons as well.
I don’t know that there is any definitive answer to this question, but here is my take on it:
I think it’s a good idea to convert certain elements to text so that they can be copied or manipulated. If you have a phone number, you may want that to be readable so that anyone with an automated dialer can click and complete the call. Certain email programs might automatically convert an address to a link to the map. Those features won’t work if any of these elements are flattened into the jpg.
For those mobile email clients that will not render the image on the screen (either because it’s just showing the preview or hasn’t yet downloaded the content) it’s useful to see some of the alternate text (and body content) before viewing the full image.
I know you said that you are sure your clients won’t have images blocked, but you can’t really rely on that. A well-meaning administrator who makes a change to the firewall could accidentally block all incoming images to the entire domain and your email will be worthless.
Lastly, an HTML email with one line of code to load an image has a high possibility of being flagged as spam.
I hope this helps!
What about bandwidth concerns, for users viewing your email on a mobile device? If it's a large image, do you want to blow out their data caps?
Or users using assistive technology, for visually-impaired people. Such as a screenreader(text to speech).The real text is helpful for scenarios like that.
Here are some examples of what I mean:
google.com - focus is set on the "search" box
gmail.google.com - focus is set on the "user name" field (actually, most web email clients do this).
stackoverflow, ask a question - focus is set on the "title" box.
Sometimes, this is a convenient feature - e.g., on Google. From a usability standpoint, however, is it really considered a good feature to have on login pages?
Personally, I have often entered my user name, started to enter my password, then the page finished loading and had focus put back onto the user name field. Unfortunately, since I have complex passwords that force me to look at the keyboard while typing, I fail to notice when focus shifts. I often wind up typing my password in the unmasked user name field for anyone standing behind me to see.
Another situation, less dangerous but still annoying, is when I'm typing a url in my address bar while my homepage is still loading. As soon as it finishes, however, and if I'm not done entering the url, focus is stolen from me and put on some other field.
Should websites and/or browsers be programmed so that focus won't change if the user is already interacting with the site or the browser? Do problems like this bother ordinary (i.e., non-programmer) users?
These are really two separate questions with different answers:
Q: Should focus be given to the input field the user is most likely to use?
A: Most definitely yes, if "most users" really is 90% or more.
Q: Should this happen when the webpage finishes loading?
A: No. The "onLoad" event is a pretty stupid place to put this. The input field should get the focus as soon as it appears - it's usually completely irrelevant when the page finishes loading. Just put a <script> tag that sets the focus right after the input element itself.
I personally hate it when websites assume the focus. The main reason is that on my laptop, if I'm using the track pad and hit the backspace key it will automatically navigate back to the previous page. If focus has been placed on a textbox it will treat the backspace as tho I'm trying to delete a character.
My personal preference (and this has very little to do with best practice) is that it nothing should have initial focus, but the first tab will take it to the element that you want to have initial focus.
The same happened to me in Gmail, I find it slightly annoying, especially since it should be easy to circumvent:
In the OnLoad event handler, check if the input boxes (username or password) already contain text. If this is the case, do not change the focus.
As with all simple solutions, I would not be surprised if there were some strange side effects that render it unpractical, but I would give it a try anyway.
Oh, and if it works, why don't you send an email to Google? ;-)
That being said, I consider this behaviour a usability glitch, something that is not a bug, but slightly annoying. Don't annoy your customers. Fix it.
I think only we programmers have the habit of typing even before the page gets loaded ;-)
Most of the non-programmers friends I have wait till they see the "Completed" signal from the loading area.
But the 2 issues above are les annoying than having to move our mouse pointer/use tab everytime to type in what we want (username, password) in sites which do not have focus on a particular control.
"Should websites and/or browsers be programmed so that focus won't change if the user is already interacting with the site or the browser? "
I think browsers should be enabled to do this than the websites. Becauase it will be another trip back to server and can be frustrating for connections with low speed.
Overall I think this is just another minor issue/annoyance which we can live with. As I said only we programmers jump in type even before the page loads. Most of my friends dont know that they can type before the page gets loaded :)
There are sites where you acutally have one usecase a normal user uses keyboard for (normal user - as some, like me, use keyboard to navigate also). Sites like Google search actually expect you to just enter what you're looking for and hit enter.
Sites with multiple input areas and multiple exit paths though sometimes put initial focus somewhere too, and then it gets annoying. It gets even worse if they haev some odd tabbing order of their input areas - so they actually force you to use mouse.
I personally don't see the changing of focus when site finishes it's loading as an issue, not for a general user. But, as I mentioned, if it's really useful, it's a matter of what's the usecase in your particular application. And this might be a matter of showing the application in it's beta-stage to some people and performing usability tests.
Yes, focus should default to the most likely place for a user to start typing. Not doing so is textbook bad UI design.
When focus defaulting interferes with something you're already doing, this isn't an inherent problem of focus defaulting, it's a failure of an inadequate implementation. This, among other reasons, is why I put together a generic 'smart' autofocus script that does things like leaving you the hell alone if you've already started typing.
(Yes, I know it's hairy. Most of the hairiness is dealing with cross-browser issues -- a failing of Firefox, actually, for once.)