window.open equivalent
I have this Javascript which opens a new window with some specific settings:
window.open('courses.php', 'courseware', 'toolbar=0,scrollbars=1,location=0,statusbar=0,menubar=0,resizable=1,width=800,height=600,left = 440,top = 225')Is there a way I can make the current window have those setting without completely opening a new window? Maybe like:
window.changeMe('courses.php, 'courseware'...)
Is there a single method that does that, or can I combine some methods to accomplish the same things?
Thanks
webwiz posted this at 05:02 — 1st November 2007.
He has: 629 posts
Joined: May 2007
Not in any of my browsers, you can't. JS is not allowed to resize windows or remove the status bar here. If that's what you are trying to do.
To resize a window, try "this.resizeTo(w,h);" where w and h are the width and height you want. Can't help with the rest, though.
Cordially, David
--
delete from internet where user_agent="MSIE" and version < 8;
teammatt3 posted this at 00:38 — 2nd November 2007.
He has: 2,102 posts
Joined: Sep 2003
I tried it with "_self" as the second parameter, but it didn't work.
Everyone's got a stupid pop-up blocker that kills everything grrr. What to do, what to do...
Abhishek Reddy posted this at 10:08 — 2nd November 2007.
He has: 3,348 posts
Joined: Jul 2001
Why do you want to mess with the user's window? Can you accomplish your goals without doing so? If you absolutely must do it, then have you considered delivering a desktop application rather than presenting it on the web?
teammatt3 posted this at 17:00 — 2nd November 2007.
He has: 2,102 posts
Joined: Sep 2003
I believe messing with the user's browser on a website is not the best thing to do in most cases. But when it's an online courseware program that people login to and don't expect it to be like a regular website, I think it's ok. Especially when it enhances the functionality and design of the online program. The old courseware program didn't require any changes to the browser, but the new one I developed does, and people are liking it because of the extra functionality. It almost looks like a custom browser window (there's a back/forward/refresh button, address bar (displays where they are in the courseware with breadcrumbs) and "browser" buttons for the tools they need throughout the online program. I just don't like the fact that when they login, I have to create a new browser window (which pop-up blockers kill), to do that.
Nope. That was one of the selling points of the courseware, that it's available online. All the content is updated automatically, and users can use it anywhere in the world, on any internet connected computer, and they don't have to download anything. And plus, I've never done desktop programming, and that will present new problems and challenges for me
.
Abhishek Reddy posted this at 17:31 — 2nd November 2007.
He has: 3,348 posts
Joined: Jul 2001
There's the rub. If you're trying to achieve that kind of universality, then you don't want to resort to fiddling with browser windows. There's nothing to say that it will work in any browser, with any set of extensions/plugins/settings.
For example, imagine a user at a kiosk or some other locked-down computer which might not permit easy use of multiple windows. Will they be able to use your system easily? What about a blind user using a screen reader? Or someone temporarily using a text-only browser in a terminal?
Maybe some of those cases are outside your scope. Maybe not. There might be others that I didn't mention, though. Have you considered them?
That's not to mention browser configurations in more prevalant scenarios. There's pop-up blockers, Javascript being disabled, window manipulations being locked, forcing popups into new tabs, etc. Which is exactly what you're running into, and what you should not want to break.
Try to make your web applications fit within the common constraints we already have. There's quite enough room for making creative or innovative interfaces without interrupting certain well-established workflows.
Since you didn't answer the question before: is there no better or equally effective way to accomplish the same goal?
teammatt3 posted this at 20:43 — 2nd November 2007.
He has: 2,102 posts
Joined: Sep 2003
But we can look at our demographics, web stats and set a reasonable expectation that our online program will work on 99% of computer that our customers use. I think it's easier to get that kind of success on the web then with software, but I could be wrong; I don't work with software
If their computer can't handle multiple windows, they're blind, or a text-only browser user, yes, they will have a problem, and I know that. But once again, what percentage of our users are in that situation? Very few. (We also have live lecture classes, so they could take those).
Not really. The cost of developing a program catering to that 1% who can't use our program will not give us a good ROI. This is a business, profits are important. There may be legal issue with not having the site fully compatible with blind users, but it is too early to tell if there is any merit to that.
The requirements for our courseware state that javascript must be enabled, cookies and all that crap. If they want to disable that stuff, it's tough cookies for them! It's a reasonable expectation that they'll have that stuff enabled to use the interactive courseware. The people who have that stuff locked down know that it causes problems on many websites.
You're talking about a browser window, but inside the courseware they don't know they're technically browsing a website. To them it feels like a desktop app that just happens to be on the web.
There could be, but will the bossman want to pay for the developers to redo the flow of the courseware just so it doesn't have to open in a custom browser window? Will the 6,406 current users care that it doesn't open in a pop-up? No. But will the 1% of people who want to use our couseware that can't be happy? Yes. But could they pay for the development costs? Not for a while.
I understand what youer saying but the courseware works fine for the users, it just bothers me I can't change the settings of a window
webwiz posted this at 22:16 — 2nd November 2007.
He has: 629 posts
Joined: May 2007
I don't know how appropriate it would be for your case, but I had a situation where the site designer wanted to open new windows; instead, I persuaded her to use some JavaScripty goodness.
In this case, it is an image gallery. With scripting active, the full-size image comes up as a page overlay; without scripting, the image opens in a new page (and the visitor returns via the back button). Feel free to use any code you may find useful:
www.aniashreeve.com/gallery/drawings.html
Cordially, David
--
delete from internet where user_agent="MSIE" and version < 8;
Abhishek Reddy posted this at 23:27 — 2nd November 2007.
He has: 3,348 posts
Joined: Jul 2001
Delivering a web app can be a good path to take for that very reason. But then you defeat the purpose when you then begin excluding users for otherwise peripheral reasons.
In fact, this is a self-fulfilling thing because only those who like the site because it works for them will tend use it.
I don't know your target audience well so you might be right. But for a random sample of web users, you're not. I'm assuming that this site is essentially catering to a general audience. Certainly if it's the kind of audience for whom delivering a desktop app will cause portability problems, then you must be looking at significant variety.
Target market groups change and grow over time. Do you really want to lock yourself into this decision so early on?
I'm going by what you said, which was, "users can use it anywhere in the world, on any internet connected computer, and they don't have to download anything". Not true if they find themselves at a kiosk or internet cafe, or if they happen to use a standards-compliant but less common web browser, etc etc as stated already.
What I understood from that earlier post was you were aiming for universality, which is good from a business perspective also. But then you discounted a load of relative minorities, which isn't good for universality. One of us isn't sure what you mean.
Remember that you incurred a load of costs in developing a complex application in the first place, and it ended up excluding those people. The same or less cost could have been better spent creating a reasonable web application that didn't exclude them, without the wasteful bells and whistles. Not to mention the ongoing costs of an accessible site will be much lower.
This is not much different to saying they must use IE only. If the user visits with a standards-compliant browser, then they can reasonably expect the site to be fully functional. If they visit with a non-standards-compliant browser, or with some strict configuration (popup blocker especially), they can reasonably expect the site to gracefully degrade and still be fully functional for them. And regardless of their software, they can reasonably expect you not to interfere with their workflow.
Firstly, you can, if you really must, achieve simulations of desktop apps on the web. This is really useful in a lot of widgets where you can't possibly avoid it. And that's cheaper when the program, by nature, is inaccessible to a some kinds of users anyway (like image editing for the blind).
Secondly, consider whether either the web-ness or the desktop-ness is entirely necessary. If it's not essential that the program be delivered on the web, then you can write a full-blown desktop app that still uses the network but gives you greater control of the interface. If it's not essential that the program be like a desktop app, then make it more accessible on the web.
The way you're setting it up, it sounds like you've got the worst of all worlds. You don't get decent control of the interface without losing users. You still have serious portability issues if you want to be universal.
Thirdly, a normal web-app structure is not a bad thing. If you don't have particular widgets that need to behave like a desktop app, then why not use a Gmail-esque interface? Why lock out some users just for the general feel of a desktop app when it's not necessary?
Right, in that case the developer (or whoever) gets to wear the been-there-done-that t-shirt of scoping failure. If the bossman shouldn't have to pay for the mistake, then neither should his customers. Why punish them?
That should ring alarm bells, imo. You're really going against the grain in a big way if that's what you want.
However, for all that, your site will probably keep working for the majority of users and you may be satisfied with that, so that's totally up to you. I'm only arguing for posterity. And don't expect any sympathy for not being able mess with my windows easily.
teammatt3 posted this at 03:30 — 3rd November 2007.
He has: 2,102 posts
Joined: Sep 2003
True, but my guess would be that that is the case when the entire website is only compatible with certain user agents and configurations. When they can browse the regular website and buy the program without a problem, it isn't so. We'd hear about it when they are pissed because it doesn't work for them.
Don't quite understand what you're getting at, but I think there is a wider variety of desktop computer configurations than there are browser configs. For a desktop program to get to the web, you'd probably have to go through windows firewall, user's personal firewall, their internet settings, and probably a ton more, just on the Windows OS. And then anytime someone calls up, you have to figure out how to configure the user's stupid firewall they don't know how to use.
And so do programs. There's no telling if they'll want to completely abandon the web operations, or move to desktop only, or maybe even on cell phones. This online program works, and will work until IE and FF set javascript off as a default and disable cookies
When I said "users can use it anywhere in the world, on any internet connected computer, and they don't have to download anything" I didn't think you'd take it so literally
. I assumed we could exclude unreasonable configurations and uncommon users. You can't expect your Commodore 64 with a NIC in it to use the courseware.
The "wasteful bells and whistles" are what separate us from the completion and make our courseware better than others. Crappy example, but would you rather rent a limo with a wheelchair ramp and a brail manual, or a mini bar and a TV in its place?
Reasonably expect the site to be fully functionally if their browser is locked down? No way! There's no way I'd expect a website to be fully functional if I didn't allow it to catch my actions, or keep track of me on the website.
I think we have decent control of the interface, and, as far as I know, we aren't losing users because of it. If anything we're gaining more because people like the feel of our courseware over the competition.
By locking out some users, we're gaining other users because our courseware functions better than other courseware programs, like I said above. I'd rather have a majority of customers using our courseware and a minority using the competition.
Is it a mistake to make something a majority of people like? Because 1% or whatever don't like it or can't use it, that suggests failure? Not in my book.
Well for that comment I'm going to set your homepage to a page where the browser jumps around everytime you try to close it and I'm also going to find a way to disable clicking so you can't click the browser menu options
...
Abhishek Reddy posted this at 08:32 — 3rd November 2007.
He has: 3,348 posts
Joined: Jul 2001
Or they will simply not say anything and ignore your offering altogether, especially if perhaps the competition says that their product works for everybody.
But all that is irrelevant anyway, because you're defeating the point of being on the web when you start locking into certain browser configurations. It is reasonable to expect the user to allow a naturally networked desktop application to get on the network. It's not reasonable to expect the user to switch browsers or change standard workflows just to get a web program to run -- especially when it could be made to function properly without the extras.
That's absolutely the point: your product won't cope with such changes because IE and FF and popup windows and whatever won't work on a cell phone, or any given platform.
It's definitely a strong disadvantage of delivering a desktop app, and a benefit of a web app. But only if the web app adheres to principles of universal accessibility. If you lock into a narrow set of configurations, it's no better than a desktop app.
Obviously we have different opinions on what is reasonable. Cookies? Ok. Scripting? Ok to some extent -- if it can't be avoided. They're kind of essential for state and interaction. Popups? No.
Firefox, a browser you want to support, has the ability to redirect new windows into new tabs instead. This is a great feature, and you as the website provider have no right to dictate whether the user should use it or not.
Taking what you said literally, it is a noble goal, even from a business perspective. If you follow the W3 link I posted in my last post, you'll find the business case for universal accessibility and usability explained very well.
Yeah, probably the one with a mini bar and a TV. But that's a false dichotomy. It's not like the bar and TV preclude the inclusion of a wheelchair ramp and a braille manual. That's the beauty of the digital world -- it's even easier and cheaper to pull off universality than it is in the physical world. All it needs is a bit of foresight.
Inaccessibility is rarely something that makes a product better than another. Unless your whole strategy is based on some kind of exclusivity -- which it clearly isn't, since you said you wanted more customers. I know less about your product than I do about your target audience, but it already sounds very strange that scripting tricks are what make it superior. I would have expected something more substantial in the way of design, usability, functionality or something -- all of which can be done with universality.
It doesn't have to be locked down totally. You can probably assume state and interaction (though there are ways to degrade gracefully if they aren't available too). But to assume the window object is an unpleasant business. As a close analogy, similarly for input devices: links can be used in a number of ways, not just activated by click.
There's nothing I can say to argue that. I can talk about the general case, or hypothetical special cases, or my experience. Or I can question whether your knowledge of those things is sound. But if you're convinced by it, then so much for that, you can ignore my advice.
Hoping not to turn this into an involved discussion of economics, I can say that aiming for maximising market share is not necessarily a worthy goal. Delivering a good product -- profitably -- would be my priority; if that leads to a high market share, then great. Otherwise, it's no big deal.
More important than market share would be fully capitalising on the web, hence maintaining standards of universality, the semantic web, good design practices, etc, while delivering my application. Probably not coincidentally, I believe that this in the long term is typically better for maximising market share. If those aren't your views, or you don't think they apply, then as I said, feel free to do as you please.
Nightmare! (Except I can live without clicking as I rely on the keyboard mostly!)
Want to join the discussion? Create an account or log in if you already have one. Joining is fast, free and painless! We’ll even whisk you back here when you’ve finished.