Related
I am very very green & have almost no experience in coding. Usually I record a macro & then tweak it to do exactly what I want. However, I am trying to create a script (either *.bzs, *.bbs, *.bbh, *.vbs, *.js, *.ebm) that can pull a single piece of data from an open tab in Chrome. We use BlueZone Mainframe Display at a call center & I'm trying to pull up customer information when they enter it into our phone system which is Cisco Finesse run on Chrome. As of now we have to copy & paste it from one screen to another & I'm looking to automate that. In theory I feel like this should be very possible but don't know where to start. Please help!
What you're probably looking for is a Chrome extension. Chrome extensions have the ability to interact with multiple tabs in a browser window--e.g. copy data from one tab and paste it into another. However, without much programming knowledge, this is going to take quite a bit of effort on your part.
Here are some resources to get you started:
https://github.com/orbitbot/chrome-extensions-examples
https://developer.chrome.com/extensions/getstarted
Nowadays it appears that many webpages want to use my cpu/harddrive/bandwidth in order to show me their ads/pages/information in beautiful but expensive ways.
Often I like these new pages, but sometimes I'm a curmudgeon and am just annoyed that my fan starts spinning and the EMF loads rise when I open the pages.
Is there a browser/plugin that I can use to throttle, best case, and/or monitor, worst case? I am not very knowledgeable of the Reactive JS, etc techniques, so I am hoping there is an easy solution?
thank you!
Anne
ps Normally I use Firefox but of course I have Chrome on my machines (win8, win7, mac 10.8) as well.
You need a client side javascript manipulator.. they are known as User Scripts... For firefox, you want something like grease monkey.... its worth a google... This is not the simplest method, but most effective.
Otherwise you will just want a ad-remover addon for firefox.
Example For Chrome: https://chrome.google.com/webstore/detail/adblock/gighmmpiobklfepjocnamgkkbiglidom?hl=en
They simply search for common code that are used to display adverts (like adsense) and will remove the code from the webpage anytime you view/load a page.
The GreaseMonkey/UserScripts path would be more if you want to customize how your browser interacts with web sites.. For example, you could say for every image on a webpage to be hidden/removed and so on..
As for monitoring, throttling.. Well, you can monitor.. but to throttle.. well that would require a application/proxy that goes between your browser and net connection.
There was one i used years ago that would allow me to simulate a 56k modem speed while developing web pages.
Monitors: https://addons.mozilla.org/en-us/firefox/collections/smayer97/for-managing-bandwidth-usage/
Throttle/Limiter: http://www.netlimiter.com/
OP, in Firefox 68+ (and probably earlier as long as it's Quantum) you can open Tools, Web Developer, Network, or CTRL-SH-E and see how long each element on a page takes to load. It actually has a lot of info. From there you can tell which ad servers are overloaded and take a while to load. Ad servers often slow down a page load because they are busy, but so do larger animated images shown as ads, or ad videos.
I know this isn't exactly a throttle, but it will help you find out more details of what is going on in a specific web page. FWIW, I simply block all ads on most pages and that helps increase load time and reduce bandwidth usage from Firefox.
Intent, hooks, API, integration, dozen of cryptic javascripts, xml schemas, URL interpreters, helpers, frameworks...
It's 3 days that i'm reading blogs, SDK, tutorials to achive a very simple goal: open Instagram by clicking an URL in the Android browser. I find it a bit incredible that i needed 5 minutes to make it on iOS. I don't even know what code i should share since i don't even succeded in having an error... at least it would be something!
To make it short i have an Android phone. I open the browser to visit my website. Now i want to add a link to open Instagram camera. On iOS i simply reference to:
Open Instagram
Take a picture
Is it really that hard to code the same thing on Android? I'm not looking to make it inside another App. It's just a normal website.
After a lot of researches and tests - yeah, even more :S - i can finally state that it's not possible unless you want to force your visitors to manually download additional contents. I don't like it. It isn't an elegant and easy solution.
Please notice that i'm only talking for websites. You you are developing an App you can achive this quite easily with intents.
More and more applications are moving to the cloud: Google Docs for productivity apps, Meebo for instant messaging, Gmail for e-mails, Salesforce for CRM, etc.
Yet, I've noticed that, unlike their desktop counterparts, very few of those web apps leverage the mouse's "right click". Most of the time, when right clicking in a web app, I get the standard browser right click menu.
I don't believe it has to do with technical implementation since modifying the right click menu is quite trivial in Javascript.
Is there an actual reason that I am missing?
EDIT: The most popular reason seems to be that it's not what user expect. Another mentioned reason was that some users disable Javascript - which is a valid answer -, but in our case, we can discard this possibility since we're talking about applications that require Javascript regardless of the right click option.
Now, let me expand my question a bit:
Do you think it should stay that way (do you really find the default browser right click menu useful) ?
Would you like to see more application-specific right click menus where they could improve the user interface ?
Most users expect the right-click menu to bring up the browser context menu, so doing it to bring up an app-specific menu is not something they would try.
Mac don't have a "right mouse button", likewise with a lot of touch screen phones etc.
Even on a windows application most normal users (not programmers or power users) don’t think to right clicking when they wish to do something, if they have not learned it off by heart to do the given task they wish to do.
(Also right clicking on most web pages brings up a menu that a normal user does not understand, so they don’t try it more then once.)
So you always have to provide another way of doing the operation anyway.
I believe a very valid approach to web applications is to still keep all the browser features enabled, such as back button, opening things in new tabs, bookmarking, changing font-sizes, and so on.
The browser's right-click context menu is something that I do not want to have taken away by an app.
Now, when you start moving the web app out of the browser into its own window (turning it into a dedicated application, such as Fluid does, and I believe Chrome OS will), without URL bar and back button, then we can talk about the context-menu.
It is not how people are used to work in their browser, you shouldn't change default behavior. Users aren't expecting something to happen when they rightclick.
Just for completeness: Opera has no oncontextmenu and no simple possibility to suppress the context menu on right click.
Giving javascript control over right-clicks gives you something like this: http://periodic.lanl.gov/elements/24.html. I really love this website, but its attempts to keep me from copying text or images (whatever it's trying to do) seriously interfere with my web usage patterns. I always open things in other tabs. I always the right click menu to access the "back" command.
It also irritates me to no end when some web site has a flash animation somewhere that steals my control key (so I can no longer Ctrl+Tab to flip to another tab.
My bottom line: web applications can't supersede the local computer's built in commands. If a web application starts taking over control keys, right clicks, etc., it has crossed the line between local and remote applications. That is a very important line to keep crystal clear.
As others have stated, this is due to history and what users are used to. But I guess this will be changing eventually, as web applications gain more and more importance; currently web apps are "web pages" in a "web browser" app, which is quite weird, when you think about it. It's not the web browser that's the interesting thing any more, it's the web app. Why should it run inside something called a "browser"? At least it shouldn't be that prominent to the user, even if it may make sense technically.
Actually we're seeing this with Google Chrome. It's definitely way more minimalistic than anything that came before. It's almost a "plain window to the Web".
Right click is an expert shortcut both in desktop apps and in the browser. Expert love it, while non-experts ignore it or use it only by rote for specific situations without really understanding it (they probably only use it at all because some expert user told them to). That’s okay. There's nothing wrong with providing something for experts only, either for a thick client or a web app. So, of course, web apps would be better if they included application-specific right click menus. They would also be better if they included accelerator keys for their commands, mnemonics for their pulldown menus, double-click for default actions, and drag and drop for selection, copying, and moving, while we’re on the subject of supporting experts.
Let’s be honest: The reason we don’t do these things for experts is because we don’t want to be bothered with the extra work, not out of some concern about confusing users with the unexpected. And that’s a valid point: a typical web app is used less than a desktop app. “Expert” web app users are thus rarer –few use the web app enough to discover and use the expert features. So why devote resources to something to benefit so few users?
Nonetheless, I want to encourage designers to have application-specific right click menus in their web apps. It is necessary if you want your app to be as usable as a desktop equivalent. If you do have application-specific right click menus, follow these rules:
All right-click menu commands should be available through a separate means, such as a sidebar menu. With right-click being an expert shortcut, you need to provide non-experts access to the same functionality in a way they’re used to. This rule is a standard (e.g., MS Windows), despite the fact that browsers (e.g., MS Internet Explorer) blatantly violate it. This rule also addresses the concern of users who disable Javascript.
Do not remove browser right-click commands that are still relevant. The user should still be able do things like save images on a page, copy a block of text, and open a link in a new tab. In fact, you should try to preserve the order of the browser commands as much as sensible. In general, follow the standards for menu item organization and order. This addresses the concern of the right-click menu being unexpected: As long as the same commands are there in pretty much the same order, it’s no cost to the user who is used to right-clicking for the browser commands.
Use right-click menus consistently. Everything that can have application-specific commands should have those commands available by right-click. If users have to start guessing what does and doesn’t have a right-click menu, they’re just going to give up on it. On the other hand, if they discover it for one item, it’ll encourage them to try it elsewhere, and you want to reward that.
Encourage right-clicking by showing it used for application specific commands in your advertisements, demos, and documentation. You may also want to explicitly show drop-down arrows on your pages (maybe just on mouse-over) wherever app-specific right-click is available. Some expert users will discover your application-specific commands anyway because they right-click for browser commands, but in many situations, the browser right-click commands are so unhelpful even experts don’t right click, so you may have to “push” it a bit.
It's not what users expect.
It's also not particularly "discoverable": like old-school Flash web sites where you had to roll your mouse over a graphic to get the site to do something, right-clicking is not necessarily intuitive.
You shouldn't fiddle with the right click because of a a little thing we call Best Practices! Don't take away my rights as a user to control my experience! I want my right click to do what right clicks do!
The best practice is to make this sort of thing optional to the user. If you want to modify this behavior, make it something users can control in their profile or in the application settings.
For example:
(click to enable)
[ ] Use super special awesome right-click menu
Also, because some people may not have a two-button mouse (I'm looking at you, Apple users).
It is due to a inconsistency between the concept of browsing (which is browser centric) and the use of a web-application (which is application centric, the browser being only the renderer). The right click button would make sense in the second case, but as the web is made for browsing resources, this introduces an ambiguity it will probably never be solved.
Kind of interesting, the fact that the most touted deficiency in macs is the single button mouse, and then the most used interface in the world, the web, is single-button centric.
Personally, the only time I would do it is if I wrote an app which ran inside a plug-in which emulated some sort of editor. Silverlight has this ability now, but I would use it sparingly.
As i read in your forst anwser this is true it would be in the context menu it might mess with some things but as i have madde a btoolbar thta floats for my site to do anything you can use keyboard shortcuts so i see a mild and doom future for right click at all i see toolbars everywhree on websites today
I see two reasons. First of all, people might have javascript turned off, today that might not be the biggest issue of all but it's been following developers since the dawn of web-dev. Which brings us to the second reason, it's not what the users expect.
If you were to talk to someone about usability on the web and you had "hidden" features which were only made visible on right-click(browser context menu popup), this would probably be counted as bad design just because most users aren't use to the idea that the web is evolving into something more than just links and left-clicks(navigation clicking).
I'm currently building a project and I would like to make use of some simple javascript - I know some people have it disabled to prevent XSS and other things. Should I...
a) Use the simple javascript, those users with it disabled are missing out
b) Don't use the simple javascript, users with it enabled have to click a little more
c) Code both javascript-enabled and javascript-disabled functionality
I'm not really sure as the web is always changing, what do you recommend?
Degrade gracefully - make sure the site works without JavaScript, then add bells and whistles for those with JavaScript enabled.
Everyone else has committed good comments, but there are a few other considerations to make.
Sometimes the javascript will be hosted on a different domain, and be prone to timeout.
Sometimes that domain may become inacessible, while your site remains accessible. Its not good to have your site completely stack itself in this scenario.
For this reason, "blocking" scripts ( ie: document write inline ) like that present in google's tracker, should be avoided, or at very least, should go as late in the page as possible so the page renders whether or not the domain is timing out requests or not.
If you happen to be serving JS from a broken/malicious server, by intent or by accident, one can halt page rendering simply by having a script that serves that javascript which just calls "sleep(forever)" once its sent all the headers.
Some People Use NoScript
Like the above problem, sometimes the clients environment may block certain script sources, be it the users choosing, or other reasons ( ie: browser security satisfactions, odd antivirus/anti-malware apps ). The most popular and controllable instance of this is NoScript, and I myself paranoidly block some of the popular tracking/advertising services with it ( some proxy servers will do this too ).
However, if a site is not well designed, the failing of one script to load still executes code that was dependant on that script being present, which yeilds errors and stops everything working.
My recommendation is :
Use Firebug
Use NoScript and block out everything --> See Site still works
Enable core site scripts that you cant' do without for anything --> See site still works and firebug doesn't whine.
Enable 3rd party stuff --> See site still works and firebug doesn't whine.
There are a lot of other complications that can crop up, but satisfying the above 2 should solve most of them. Just assume that, for whatever reason, one or more resources that comprise a page are viable to spontaneously disappear ( they do, all the time ), and you want the page to "survive" this problem as amicably as possible. For the problems that may persist for < 10 seconds, its not so bad, refresh the page and its fixed, but if its a problem that can occur, and severley hamper usability for an hour or more at a time.
In essence, instead of thinking "oh, theres the edge case users that don't have javascript", try thinking more a long the lines of "its really easy to have something go wrong, and have ALL of our users with broken javascript. Ouch! Lets try make it so we dont' really hose ourself when that does happen"
( I've seen IE updates get rolled out and hose javascript for that entire browser until the people whom wrote the scripts find a workaround. Losing all your IE customers is not a good thing )
:set sarcasm
:set ignoreSpelling
:set iq=76
Don't worry, its only a 5% Niché Market
Nobody cares about targeting Niché markets right? All those funny propeller heads running lynx in their geeky stupid linoox cpus, spending all their time on the intarwebs surfing because they have nothing better to do with their life or money? the crazy security paranoid nerds disabling javascript left and right because they don't like it?
Nobody wants them as your primary customer now do they?
Niché markets. Pfft. Who cares!
:set nosarcasm
Consider your audience
"Degrade gracefully" is generally the best answer. But lots of sites now depend on JS - especially AJAX.
Consider your audience. If your site is aimed at extremely tech-savvy people, the chances of them not having javascript are small, and you can notify them to turn it on if necessary.
If your audience may access your site with mobile devices, don't assume they have JavaScript, and don't even assume they support CSS properly. Aim to degrade gracefully all the way down to bare HTML.
I've learned a lot from my question: What's With Those Do-Not-Use Javascript People
Go with Ajax and Web 2.0. It's the way the web is going and it's wonderful. Isn't Stackoverflow great to be on? It's not quite as nice with your Javascript turned off.
Once you have your site ready, but before you let it go live, test it with Javascript off, and just add whatever you feel you need to make your site appear and function to them. You only need to add what you feel is essential.
Remember, except for visually impared people using screen readers, the others have chosen to turn javascript off. They can also choose to trust your site and turn javascript on for your site if they want to use all the functionality you have. It really is their choice.
As other have said, it should "degrade gracefully".
In other works, it must work without Javascript (period). It doesn't have to work well. The folks who've disabled Javascript know the limitations that causes and have accepted them. But if you are trying to sell them something, it's important that they can still buy it.
On the site I'm designing, there's a javascript-based fly-out menu. With Javascript off, all the flyouts are always open. It doesn't look as cool as it would with JS, but it can still be used to navigate the site.
It depends on how much time you have to develop and maintain both solutions, and how much the non-javascript users are worth to you.
My e-commerce site relies heavily on javascript, and in over a year and a half, I've not received a single complaint.
In fact, I don't think I've seen a single visitor with javascript disabled in any of logs since I started.
That doesn't mean they're not out there. It just means that either (a) they're a tiny percentage, (b) they're not interested in what I'm selling, or (c) both of the above.
Code your web site with support for the bare minimum kind of browser. Then more people can use your site without frustration even if they don't have all the bells and whistles--like Flash, Javascript, and Java--enabled. It may not be practical to continue support for ancient browsers, say Netscape Navigator 4, because a user can be reasonably expected to keep their computer up-to-date. However, features like Javascript, Flash, and Java can be security holes in old or modern browsers, as well as being an annoyance.
Neither of my parents keep Javascript or Flash enabled because they've had too many experiences with them slowing down their already slow connection, crashing their browsers, or being more of an annoyance on sites that use it stupidly (which is a lot of them...) than a useful feature. It's just bad design if, for example, your form requires an AJAX call be made and you can't actually hit a submit button to send the form when Javascript is disabled.
My mother was recently quite frustrated to discover that she is now unable to click through eBay results pages because each one requires Javascript. The only way she can see the next page of results is to turn on Javascript or to show more results per page. Now what reason would there be for page links to require Javascript while the 'results per page' links are just plain links? They should all be plain old HTML links. Maybe Javascript could be used to add some whiz-bang to the navigation, but a user should not be punished with a bad interface for having Javascript disabled. It's stupid on eBay's part, and it causes undue hassle for their users.
I am one of those that uses 'No-Script.' And I can tell you that sites that use javascript and don't work without it enabled is extremely annoying, stackOverflow... No we don't expect it to be very fancy, if I upvote load a new page that says "Thank you."
We expect to be able to use the site with reasonable limitations, don't ever display a page that says JS must be enabled, though, even if the site is crap without it. And yes if your site convinces us to stay we will enable. A function that isn't in common use on the site can also require javascript.
Please note that your site should also look good with no JS or CSS, if nothing else it is good for Bots.
As others have pointed out some phones don't have JS, this is changing but another good reason to have reasonable non-JS. I suggest code with non-JS and add JS after the former works, there are good ways where JS can work with the non-JS layout.
It helps me in my implementations to think about it as "progressive enhancement" rather than graceful degradation. Degradation often leads you to figure out how to make it work w/o js after it is implemented, instead of making a baseline and enhancing with js.
It is essential to at least test your website is functional when JavaScript is turned off.
As orip says, degrading gracefully is very important. It should be vital that your page both looks nice and functions when JavaScript is disabled.
For a standard web site that is primarily intended for conveying information, degrade gracefully always.
For web applications:
When building a web application for a standard internet audience, I would keep the three following facts in mind:
95%-97% of potential users will have JavaScript enabled.
At times established users will need to access functionality when JavaScript is not available.
3%-5% of potential users will have JavaScript intentionally disabled.
Given fact one, if you believe that building a JavaScript reliant web application will deliver a superior user experience, then by all means do it. Doing so may help you accumulate users.
However, given fact two, you should always provide a means by which your users can access core functionality without JavaScript. Do you need to offer every single feature? Probably not. But a user should be able to get his or her work done. This will keep your users happy when they find themselves temporarily without JavaScript.
Given fact three, I would also provide an in depth tour as an attempt to entice these users to enable JavaScript.
As an aside, one of my most favorite web applications, Remember The Milk follows this approach. Also, Google's Calendar application is unusable without JavaScript. So JavaScript reliant web apps are on the rise and that trend is probably unstoppable. In my opinion this is a good thing.
(Do keep in mind that JavaScript make Accessbility a bigger problem than it is already. Please do make an effort to make your apps usable by those with disabilities.)
As said before, it depends on your target audience.
If I'm part of it, you want to make sure that your site works (if not ideally) on my phone, and that it gives me reason to turn Javascript on when I surf there with it off. Nobody expects full functionality with Javascript disabled, and anybody who uses their phone to access websites expects some issues, but you need to at least provide teasers. For a web store, make sure customers can see at least some merchandise anyway, even if they can't buy without Javascript.