How ungroup the "Open as..." context menu entry?
If I am using only 2 Profiles, I'm good
Screen of only 2 profiles
As you can see in the screenshot, I have to do two clicks for opening an url link within the other profile.
Screen of 3 or more profiles
But if I have a third profile, the context menu changes, it creates an expandable item, grouping the other profiles. That is very annoying, because I have to navigate first to the "Open as" line and then after a short delay or an additional click the profile-list appeares where I need to select appropriate profile.
Can we revert the behaviour to list all available profiles within the root context menu?
May we create a keyboard-shortcut for every profile, so pressing the asssigned button while clicking on any links, will open the url in that profile.
Or is there an extension for doing the job? I couldn find any useful information to solve this...
Thanks in advance for any helpful advices :)
(sorry for the spellingmistakes)
Offtopic:
(migrating from ff to chromium. Everyday web-based apps for end-consumers getting more focus, which means in my eyes, programmatically design gets more limited due to the main concept behind our standardized world wide web. And additionally user control gets worse everyday because that's the new key to generate money no longer just for complex & highly specialized products. e.g. timeinvestigation is enormous to through out all the bugs and bullshit extensions to get a reasonably useful tool for accessing the world wide web.)
I'm doing a training class right now and one of the games I plan on doing is a Jeopardy style of Q & A. The problem I'm trying to figure out is the buzzer. My idea is to use the projector as the question board I control. The trainees would go to an HTML page with nothing more than a single button. They would turn their monitors around to face me up front. As soon as I read the question they would click the button and it would change their screens the color red.
The button and background color change is easy enough, I got that. There are two problems I'm facing: 1) I need it so that they can't click the button until I'm done reading the question - this one isn't as important, I can just make up a rule. 2) Only the fastest person will have a red screen. To show me who clicked first. The others' buttons will be disabled.
I just have no idea how to even Google these two things. Like: "Disable button for other users"...? Or maybe, "only one click"...?
Any direction to search is appreciated. Eventually, I'd like to add other aspects to like the presenter could click an "incorrect button" then it would clear the screen and enable all the buttons again, for the answer steal.
You can do it with modern WebSocket or applications interact via TCP. However, WebSocket may be overkill for the simple application with a few teams. I faced the same problem before and developed a simple solution with PHP using Flock to write into a shared file on disk. Only request from one team gets the chance to write into that file. Stick to not to use WebSocket, the web page on client site does some polling to receive the "restart" signal from the server for the new question/round. It can run in LAN, different team gets different site, i.e. http://[server-ip]/team1, http://[server-ip]/team2.
You can have control over the round: allow them to press button/ restart, start a new question in http://[server-ip]/admin.
Further improvement can be made in several ways to facilitate your needs (i.e. assign team name, register team, use database instead of a flock file). The code is available here : https://github.com/minhhn2910/buzzergameshow
When we ask the user to allow us to use their Camera and Microphone the browser presents some sort of interface asking the user to accept or reject this action.
In Google Chrome this interface looks like this:
Our users seem to be missing the appearance of these Deny and Allow buttons.
Is there any cross browser utility that serves as "visual encouragement" for the user to click allow?
For instance, in the case of Google Chrome, something like a big yellow arrow would appear in the upper right of the page window and point at "Allow".
Agree that the default presentation in the major browsers leaves a lot to be desired. That pop-down menu bar is (typically) visually isolated from whatever the user clicked on to trigger the permission request. That is, their locus of attention is on an element that's disconnected from what they need to do next. This problem is exacerbated (1) by banner blindness (which means that people are used to ignoring animations in their peripheral vision, assuming that it's an ad) and (2) on larger screens.
So those are the issues causing the problem.
Here's a quick video walkthrough of one way to solve the problem by the site and by the browser itself, using Google Maps' "use my location" feature in the web browser:
http://cl.ly/2h2f382A143F/so-browserpermissions.m4v
(a) TIMTOWTDI =. there is more than one way to do it
(b) TIOOWTDI =. there is only one way to do it
i do not know if the case for this issue is (a) or (b), above.
The follow links may apply to this discussion:
https://developer.mozilla.org/en-US/docs/DOM/window.onbeforeunload
MSDN beforeunload | onbeforeunload event
http://dev.w3.org/html5/spec-LC/history.html#unloading-documents
http://dev.w3.org/html5/spec-LC/history.html#beforeunloadevent
... Note: There are no BeforeUnloadEvent-specific initialization methods.
please note: i am not discussing SO article 276660 "How can I override the OnBeforeUnload dialog and replace it with my own? which is about the text that the end-user sees in the dialog box; i found SO article 276660 via the first reply to this discussion: suggestion: change default for are you sure that you want to navigate away from this page? from OK to Cancel
My issue with how various browsers behave is the need to prevent the end user from losing her/his typed data because she/he accidentally clicked away from a page; such a disaster can easily occur if she/he happens to press the space bar shortly after the dialog box has been displayed; "disaster" may seem like a very strong word unless you are the end user who has just lost an hour or two of typing.
i. is JavaScript the only way to prevent this?
ii. is there some way to tell the end users' browsers to make Cancel the default?
Clarification (i hope): in a Windows O/S dialog box, it is possible to tell the Windows O/S which button to highlight as the default; for example, if the message were something like "delete all of my files", a default of "OK" is a bad idea.
SO frequently saves my text as i'm composing a question; other forums do not do the same.
i'm guessing that if my laptop were to crash as i'm writing this message then SO would give me some way to recover close to the point where i am at this moment.
Will someone please tell me whether there are one or more ways with regards to browsers, and, if there are, where to find more information?
imho, setting the default dialog box button to "OK" is far too dangerous because accidentally hitting the space bar could cause a lot of grief.
Thank you.
Should links to external sites set target=_blank? E.g. I am on www.acme.net and have a link to www.otherplace.net, should that link be:
<a href='http://www.otherplace.net' target='_blank'>otherplace's website</a>
or:
<a href='http://www.otherplace.net'>otherplace's website</a>
I was under the impression that using _blank to sites outside your domain was best practice, but now I am being told otherwise.
Some web idealists will state that you should allow the user to make their own choices when it comes to navigation - I have a lot of sympathy with this view. As web developers, we shouldn't be forcing such decisions on our visitors.
However, I also know that businesses often want to 'retain control' and so insist on spawning a new tab/window for external sites. An I understand this too - It's a very practical approach, particularly when you consider that how many users don't know how to control their own UA.
I often tend to steer a middle course between the two, by adding an image (I'm sure you will have seen many in your time) that indicates which links are external, and a note to indicate that external links will open in a new tab/window.
Not quite as 'pure' as the first option, but at least it is clear to the user how the site will behave.
found this on the w3c site
Checkpoints in this section:
•10.1 Until user agents allow users to
turn off spawned windows, do not cause
pop-ups or other windows to appear and
do not change the current window
without informing the user. [Priority
2] Content developers should avoid
specifying a new window as the target
of a frame with target="_blank".
More info here
the question you need to ask your client is "To what priority level are you aiming to achieve?"
I think it totally depends on your use case.
If you are opening a site in another domain and need to keep your site open, and I think in most cases you do, then use target='_blank'.
As a user, I find it annoying when I click on a link to another domain and it moves me from the original domain. Of course, using ctrl+click in most browsers is a way to defend against this - but why make the user do more work?
It might also be worth to mention that using target attribute is not xhtml valid. I do usually open links in external window or tab because I see that most regular users (not the advanced ones) want it that way so that they can always get back to the site they were on - usually they would go deep into the other site and then it become unfriendly for them having to click back multiple times.
So in terms of usability I think that there's more users that don't use special techniques to manually open links in new window/tab.
With regards to the xhtml validation, you might want to decorate your links with rel="external" or some similar word then use this JS function to handle new window open. I did it like this 99% of time in the last few years.
function externalLinks() {
if (!document.getElementsByTagName) return;
var anchors = document.getElementsByTagName("a");
for (var i = 0; i < anchors.length; i++) {
var anchor = anchors[i];
if (anchor.getAttribute("href") &&
anchor.getAttribute("rel") == "external")
anchor.target = "_blank";
}
}
/**
DOCUMENT LOAD
**/
$(document).ready(function () {
/**
external links
**/
externalLinks();
....
Just don't do it. Using target attributes with links presents complications for assistive technology users who may not know another tab has opened. It becomes a bad experience for these users when the back button does not work in the new tab to take them back to the page they started on. This practice can also be disorienting to people with cognitive disorders. It is best to let users decide where links will open.
You need to predict what your users want. Use target="_blank" if you expect your users will want to stay on the site.
For example if a blog post has a link in the middle of the post, it makes sense to open that link in a new tab since you are expecting the reader to return to the page and continue reading.
Some people argue that the reader could simply click "Back" when they wanted to come back to the page,
But new webpages will have more links to webpages that have more links, what happens is that the reader has to "Back" a couple of times to get back to your blog post. Either that, or he ends up "lost" in the myriad of linked pages and couldn't come back to your blogpost (you can be sure that no one wants to open History and find your page again when they are "lost", unless there is a big incentive to coming back to your page).
As it is a governmental website, this is a tricky question. I regularly see disclaimers for external sites on these type of sites. I don't know if this is a standard or not.
I think the answer is probably down to your own opinion, which should probably be based on usability and integrity.
Just make two buttons for your users: One to open in new tab, and another to abandon the current page in favor of the linked page.
[ www.google.com ]
[Open Google in place of THIS page]