I am building an extension for Chrome and Can't decide If I should use chrome.windows.create type popup , panel or detached panel. I could not find a comparative study of the three options . Any links or short description of positives and limitations of each will be helpful .
Thanks
You are having difficulty understanding it, because unless you specifically enabled an experimental feature, they are exactly the same, or rather the latter ones are ignored and a popup type is created.
Unfortunately, this means that this API is unavailable for general use until Google decides to mark it stable.
Quoting the docs:
The 'panel' and 'detached_panel' types create a popup unless the '--enable-panels' flag is set.
As for what panels are, here is the API proposal with detailed description.
Panels are windows that are visible to the user even while the user is interacting with other applications. The small windows are positioned at the bottom of the screen, with minimal manual window management by the user. This API will allow extension developers to create and use panels.
[...]
An extension opens small "pop up" windows, for example, separate chat sessions, calculator, media player, stock/sport/news ticker, task list, scratchpad, that the user wants to keep visible while using a different application or browsing a different web site. Scattered "pop up" windows are difficult for the user to keep track of, therefore panels are placed along the bottom of the screen and are "always on top".
The user would like easy control of chat windows: finding them, moving them out of the way, etc. Window management of separate chat "pop ups" is time consuming. All panels can be minimized/maximized together.
If you want a real-life example, the Hangouts extension is whitelisted to use this window type; that's how they make the chat panels:
Since chrome doesn't by default enable panels , this need to be set to display panel behavior instead of popup window . Note that popup windows can be re positioned and one can view console window , but none of it is available in panel .
Related
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 am developing a chrome extension. When I install it one of its icon is displayed in address bar. I want that icon should not be displayed after installation.
Starting with Chrome 49 (see the announcement and detailed description) all extension icons are displayed in the browser toolbar:
[...] each extension the user has installed has a persistent UI surface. By default, this will be in the toolbar to the right of the omnibox (where browser actions are now), and the user can choose to hide ("overflow") these actions in the Chrome menu.
The reason for this is to protect our users. We've heard too frequently that many users are unaware of the extensions they have installed, whether this is due to sideloading, installation by phishing, or simply the user forgetting how many and which are installed. Unfortunately, extensions consume computing resources, and may have significant security, privacy, and performance impacts. Because of this, we've decided we need to increase user visibility.
What this means for your extension:
If the extension has a browser action: Nothing! (Apart from the slightly different hide/overflow functionality.)
If the extension has a page action: The extension will be given a persistent icon in the toolbar. On pages where the extension's page action wouldn't normally be visible, the action will be greyed out, indicating that it doesn't want to act. On pages it does want to act, it will be fully-colored.
If the extension has no action: Similar to page actions, the extension will be given a persistent icon in the toolbar. It will be shown with the greyed-out look all the time.
Displaying the action persistently, even in the cases of a previously hidden page action or an extension with no action, is necessary because the presence of an action doesn’t always correlate with the extension acting. We also can’t show the action conditionally on, e.g., a per-tab basis, because there are many actions that are not correlated with any tab. In order to ensure users are aware of the extensions they have installed that could be affecting their browser, we need to ensure each extension is visible.
We've done our best to limit the functionality this breaks, and hope you understand the trade-off between developer inconvenience and user benefit. Thank you for understanding as we keep our users safe!
An end user of your extension may manually hide the icon either by adjusting the overall toolbar width (click the space between addressbar and toolbar and drag) or by rightclicking an icon and selecting Hide or Show:
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
I'm looking to build a chrome extension that allows the user to have an independent subwindow that is the same in each tab (for example you are taking notes and the notes are synchronized among each tab). Also, clicking a link should not destroy this subwindow.
One solution is to inject an iframe in each tab, and try to synchronize this data serverside and send back to each client tab, as it is updated.
This seems very tedious, plus the iframe would be provided by a third party, and I want to make it the easiest for them.
Is there a way I can have a shared dom piece and display it in its current state across several tabs?
There's an API (still experimental as of Chrome 17) that does more or less exactly what you want. If you visit about:flags, and enable "Panels" (they're enabled by default in Dev and on Canary (and on ChromeOS)), you'll be able to use chrome.windows.create with a type of panel to create a floating pane that exists independently from the browser window. That would likely meet your need.
Take a look at the Google Talk extension for an example of how it might work.
Are there any standards out there for how applications that have a system tray icon should behave?
I recently wrote an application that sits in the system tray most of it's life. I handed it to a friend, and her first instinct was to double click the icon to get at the main window (which worked). But this got me thinking. In .NET atleast, there are all sorts of different events and ways of attaching things to your system tray icon (click [left/right], double click [left/right], context menus, off the top of my head). Just thinking about it, I've come up with applications with a right click context menu (most), left click brings up the same context menu (Live Messenger), a (different) left click context menu (Daemon Tools), left click opens the main window (alot of the Windows notifications), left double click opens the main window (mIRC, lots of other applications). I've yet to discover an application that uses right double click, though I'm sure it's possible...
Are there any usability guidelines or standards as to how your application should behave under any of these particular situations?
You may want to read Those notification icons, with their clicks, double-clicks, right-clicks... what's up with that? from Raymond Chen's blog The Old New Thing.
He even includes a link to Guidelines for the Notification Area (more commonly known as the "system tray").
Unfortunately it's hard to have a standard when every one is different.
Double click to open and right click to have some sort of context menu are the ways I expect it to behave. Having an Exit command as the bottom icon on the context menu is good whenever it makes sense as well.