Browser to fullscreen - solution needed for many browser/platform combinations

[DU]

Re: Browser to fullscreen - solution needed for many browser/platformcombina tions

Brian Genisio wrote:
[color=blue]
> Jim Ley wrote:
>[color=green]
>> On Thu, 29 Apr 2004 07:54:14 -0400, Brian Genisio
>> <BrianGenisio@y ahoo.com> wrote:
>>
>>[color=darkred]
>>> DU wrote:
>>> Wow. That was completely unnecessary. A requirement is a
>>> requirement. The Boss wants it, there is little he can do to change
>>> his mind, other than show the boss that it cannot be done.[/color]
>>
>>
>>
>> This seems to be a peculiar viewpoint on the boss/employee
>> relationship, one that seems more prevalent in certain
>> countries/communities. Requirements are always negotiable, they
>> have to be, as in this case if the requirement is impossible, but the
>> developer should always let the boss know if the requirement is bad
>> (on accessibility, on cost to support, on cost to implement, on risk
>> to security etc. etc.) If you just follow orders, you are a _very
>> bad_ employee.
>>[/color]
>
> This is not a peculiar viewpoint at all. If the employee just shuts up,
> when he/she knows there is an issue, then there is a problem... I
> agree. But, if you tell a boss or a customer that "What you want is not
> considered a good idea by the community" and they come back to say "This
> is what we want", then the implementer does not really have any say in
> the requierement.
>
> People make the blanket assumption that "just follow[ing] orders" is
> what the OP is doing. You cannot make that assumption.[/color]

Until a poster says otherwise, then yes, you should assume that he's
just blindly following orders, particularly if he uses "HELP!" and
"desperate" words.

From the way[color=blue]
> the OP wrote it, it really sounds like the OP knows why it is bad, and
> the boss wants it anyways.[/color]

That's not how it sounded to me.

If you cannot convince the boss otherwise,[color=blue]
> then you either implement it via specification, or prove that it cannot
> be done. To say that "Requiremen ts are always negotiable", you are
> living in a dream world. To an implementer, requirements are _not_
> always negotiable. If a requirement is a bad idea, and you explain why,
> and the customer/boss still wants the requirment, there is not much you
> can do.
>
>[color=green][color=darkred]
>>> It is likely that the boss has seen it done before, therefore knows
>>> it can be done,[/color]
>>
>>
>> but in this case it certainly can't be done.[/color]
>
>
> I know that I have had web browsers take me into a full-screen (or a
> pseudo-full-screen) mode automatically.[/color]

It can not be done in several browsers by pure javascript force. And
even if it was doable by pure force, it would still be not recommendable
to do such and that is much more important to understand otherwise to
debate. But you never caught that.

If this is all I know, then the[color=blue]
> only thing the OP can do is come back and prove why this cannot be done.
> If one of the requirements is that the app in IE, and you can only get
> it done in IE, then that is still acceptable to a boss. Doing more than
> necessary for a requirement is often a bad move, unless the development
> time is close to free. A developer peon will not convince a boss
> otherwise. Only if nothing can be done, will a stuborn boss revist the
> requirement.
>
> The OP wanted to know if it can be done. He asked because he did not
> know. DU came back with a completely unappropriate response.[/color]


You're way out of proportions here.


This[color=blue]
> group exists for people to help others.[/color]

Wow! And you say others are dreaming?

Treating a poster like crap is[color=blue]
> less than helpful.
>[/color]

So far, you have not brought any answer to the OP. If you claim my posts
are not helpful, then why don't you start giving an answer to the OP
yourself?
[color=blue]
> We developers live in a world where we need to keep our jobs.[/color]

Is bankruptcy of your client/boss a good thing? Have you ever heard
about the dot.boom phenomenon?

Being[color=blue]
> argumentitive does not aid in that goal.[/color]

Even if that leads a website to get poor support/visit stats from users
and visitors? Even if this gets very weak score in an usability study?

Being realistic does. The OP[color=blue]
> was nothing but realistic and reasonable with the questions.
>
> Brian
>[/color]

Why don't you help the OP with clear answers and reliable solutions that
he can follow then? If none of what I said is useful, then get off my
back and answer something he can write in his web page.

DU

[DU]

Re: Browser to fullscreen - solution needed for many browser/platformcombina tions

Brian Genisio wrote:
[color=blue]
> Jim Ley wrote:
>[color=green]
>> On Thu, 29 Apr 2004 16:03:34 -0400, Brian Genisio
>> <BrianGenisio@y ahoo.com> wrote:
>>
>>[color=darkred]
>>> Jim Ley wrote:
>>> But, if you tell a boss or a customer that "What you want is not
>>> considered a good idea by the community" and they come back to say
>>> "This is what we want", then the implementer does not really have any
>>> say in the requierement.[/color]
>>
>>
>>
>> Of he course he does. the implementor always has a say, and in this
>> case as we know the implementation is _impossible_ the implementor is
>> the final arbiter as he cannot deliver, now he can accept the task and
>> fail, or he can explain up front that it's impossible and offer the
>> plausible alternatives.
>>
>>[color=darkred]
>>> To say that "Requiremen ts are always negotiable", you are living in a
>>> dream world.[/color]
>>
>>
>>
>> No, I live in the real world, and as a contractor monkey, I've very
>> little say in what I implement - you know what, I generally get
>> listend to though, because I can explain the cost of the various
>> options.
>>
>>[color=darkred]
>>> I know that I have had web browsers take me into a full-screen (or a
>>> pseudo-full-screen) mode automatically.[/color]
>>
>>
>>
>> Yep, it's possible in IE, with the caveat that un-fullscreening it
>> will cause problems which are generally unacceptable. The OP knew how
>> to do it in IE, but also wanted to do it in other browsers, those
>> can't do it.
>>
>>[color=darkred]
>>> We developers live in a world where we need to keep our jobs. Being
>>> argumentitive does not aid in that goal. Being realistic does.[/color]
>>
>>
>>
>> Learning to be a valuable employee who can add value to the company,
>> and not just do what you're told not caring if it does contribute to
>> the product will help your employment prospects a lot more than just
>> shutting up.
>>
>> Jim.[/color]
>
>
> Jim,
>
> You are not listening. Plain and simple. I have said many times in my
> posts something like "If it cannot be done, then it is the implementer's
> responsibility to show the boss/customer". I also agree that it is
> important for an employee to speak up when there is a problem.
>
> I object to the hands-down patronizing tone that DU gave to the OP. I
> dont care if what the OP wants cannot be done in IE. The OP asked a
> question, because he did not know the answer. He did not deserve the
> treatment he got. He deserved a respectful answer.
>[/color]

So far, in this whole thread, you've just been a lawyer of respect and
political correctness. You've certainly not demonstrated any kind of
javascript help. And on top of that, you claim that others - not even
you - should help him out because this is what others should do in this
newsgroup.

If there is one person who should be in the best position to educate the
boss on the judicious use of javascript - and this, in the name of the
business' survival, prosperity -, it should be the web programmer
himself. Failure to understand such duty - yes, duty: you are paid to do
so - is a big mistake to begin with. Speaking out in the name of sound
usability and respect of the user's browsers and users entire veto on
such issue is in no way suggesting that you're going to lose your job:
that's nonsense.

[color=blue]
> I still stand by my statement that sometimes, the implementer has no say
> in the matter. Here is a good example... I worked at a company that had
> the reqirement to integrate two pieces of software, that worked in two
> different operating systems. The software could not be ported.
>
> The solution was to have the two pieces of software run on separate
> machines, and communicate over the network. The customer came back and
> told us that it was unacceptable to use two computers for the task. This
> is because they did not believe they could convince their bosses to buy
> two machines for each seat of the application.
>
> We came up with a solution to integrate two OS on the same machine, and
> set up the communication. The solution was much less efficient, and
> ultimately much costlier to implement (than a dual-machine solution),
> since a virtual PC software package had to be purchased per seat, and
> the development was to exceed the cost of using two machines. It was
> also painfully complicated. All in all, both I and my boss agreed that
> this solution was much worse than using two machines.
>
> The customer did not care. They decided to pay more money, for a
> slower, more complicated solution, just so they did not have to have two
> computers. We had no say in the matter. Either we complied to the
> customer's requrement of a single system solution, or we lost the deal.
>
> What do you do in a situation like this? This is not the only solution
> that I had to implement something against my better judgement, in order
> to fulfill an unwavering requirement. It has happened many times.
> Customers know what they want, and they expect you to do it for them.
>
> Brian
>[/color]

Customers know the business goals but when it comes to web site designs,
implementation, usability and javascript, they don't know how and they
ignore what years of usability and accessibility studies have given us.
If it was only of them, we would still have blinking banner ads, popup
ads, marquees everywhere etc. on the web. Some of them went bankrupted
while others (started to trust and) listened to what trained, certified
web designers were saying.

"Human spirit works like a parachute: it works when it's opened."

DU

[DU]

Re: Browser to fullscreen - solution needed for many browser/platformcombina tions

William Morris wrote:
[color=blue]
> Jesus, DU, lighten up and read his post. Boss requirements, intranet app,[/color]

He mentioned intranet app later, not in his first post.
[color=blue]
> all that. If you can't post something constructive, at least don't
> sermonize.
>[/color]

[snipped]

I explained a few hard facts. He claimed to have searched a lot: I don't
think he has for many reasons I won't detail here.
[color=blue]
>
> Solution by tomorrow? That's a "boss" for you. The solution is "Sorry,
> can't, the technologies as they are don't allow it, or are implemented in a
> way that causes problems in the OS. What problem are you trying to solve to
> which you think fullscreen is the solution?"
>[/color]

This meets my position as well. The real issue is rarely explained and
described (overall whole web context, web site analysis, goals, etc) in
such typical post. Only the assumed solution (here, fullscreen window)
is underlined.

DU
[color=blue]
> You find the pain point, msa, and you, as the developer, suggest the
> solution. Your boss has it backwards.
>
> - Wm
>[/color]

[Brian Genisio]

Re: Browser to fullscreen - solution needed for many browser/platformcombina tions

DU wrote:
[color=blue]
> So far, in this whole thread, you've just been a lawyer of respect and
> political correctness. You've certainly not demonstrated any kind of
> javascript help. And on top of that, you claim that others - not even
> you - should help him out because this is what others should do in this
> newsgroup.
>
> If there is one person who should be in the best position to educate the
> boss on the judicious use of javascript - and this, in the name of the
> business' survival, prosperity -, it should be the web programmer
> himself. Failure to understand such duty - yes, duty: you are paid to do
> so - is a big mistake to begin with. Speaking out in the name of sound
> usability and respect of the user's browsers and users entire veto on
> such issue is in no way suggesting that you're going to lose your job:
> that's nonsense.
>[/color]

Giving an answer to the question is not necessary. The answer has been
given, and I stand by the answers given by others. The OP was asking if
it was possible:

msa wrote:[color=blue]
> So, can someone please provide me with
> 1. if fullscreen can be accomplished for each combination listed[/color]

I dont think I am out of line on how inappropriate your answer was. You
can answer it simply, or you can answer it with distain. I was
defending the OP, because I know how frustrating it can be. I know what
it is like to have requirements that are bad, and have a boss tell me
that it has to be done anyways.

The reality of the situation is this: What he wants to do can be done
in IE. If he learns from the NG that it cannot be done easily in other
browsers, then there is a good chance that browser support will be
reduced. Or, the impleneter will be asked to make it full screen for
IE, and make it look as good as possible in Netscape, Opera, etc.

And to make the blanket statement that full-screen is bad is a narrow
view of the situation. I can think of at least two situations where
full-screen makes sense. Have you ever made a kiosk application? They
are almost always full-screen. Have you ever made an application that
is meant to go on a computer as it's sole use for the computer? These
applications are also usually full-screen. (of course, there are other
solutions to both of these that do not involve making it full-screen via
Javascript)

If the application is meant to be used like normal web-browsing, I
agree. Full-screen is almost always a bad idea. In a restricted
environment, I'd have to hear the reason for full-screen. It might
actually be justified. Sometimes, a computer exists to host a single
application. In these cases, some of the normal usability rules can
(and should) be ignored. I dont know the application that the OP uses,
but I need to give him the benifit of the doubt.

But, when it comes down to it, you were rude, and I was standing up for
the OP. I did not think your rudeness was appropriate, and I said so.

Brian

[Grant Wagner]

Re: Browser to fullscreen - solution needed for manybrowser/platformcombina tions

Brian Genisio wrote:
[color=blue]
> A requirement is a requirement.[/color]

Yes it is, but it doesn't mean that the requirement flies in the face of
everything known and understood about usability and the actual technical ability
to accomplish the goal.
[color=blue]
> The Boss wants it, there is little he can do to change his mind, other
> than show the boss that it cannot be done. It is likely that the boss
> will want it done as well as possible, even if only a few browsers are
> supported. It is likely that the boss has seen it done before,
> therefore knows it can be done, and cares little on the reasons against
> it. Of course, there is nothing wrong with trying to convince the boss
> against doing something like this, but I object to your method of
> patronizing, condescending tone.[/color]

There is a lot that can be done to change his mind.

Design and develop a prototype of what he envisions. Then demonstrate it in the
browsers where it works very well. He will not understand why you are arguing
against the design when it works so well. *Then* show him the design in a
browser like Firefox where the ability to resize or open new windows is
disabled. Demonstrate that the look and feel of the site, even if it can be made
to work in both browsers, will be a totally different, and possibly confusing,
experience for the end-user if they switch between different browsers.
Demonstrate that support will be an issue, because in browser A the screen looks
like this and the controls are here and there, and in browser B, the screen
looks like that and the controls are there and here. Explain how your help desk
will, with different designs, have to determine *precisely* which browser an
end-user is running and *precisely* how they have it configured before they can
even begin to help someone having problems.

Then demonstrate a different prototype. One that works flawlessly in every
browser you show him. How it provide a consistent look and feel for the
end-user. Explain how support (and development) costs will be much lower in the
cross-browser design.
[color=blue]
> The OP started off saying that he knew it was bad. You really don't
> need to be such a jackazz about this. In your message you belittle the
> OP and insult him/her. It is childish, and not needed here. The OP was
> completely clear in his position, and is desperate for help. An answer
> such as "It cannot be done because of X" is useful. Saying "Your
> request is childish, unrealistic and disconnected" is crap. Calling the
> OP a "bad, incompetent web author who is going to fail" is also crap.[/color]

And your response offers the OP no assistance either. If you wish to help him,
then help him. I would imagine you haven't helped the OP because you realize
what a pointless and massive task it would be to develop two (or more)
completely separate designs of the Intranet application he is developing to
support the browsers that need supporting.

--
| Grant Wagner <gwagner@agrico reunited.com>

* Client-side Javascript and Netscape 4 DOM Reference available at:
*

http://devedge.netscape.com/library/manuals/2000/javascript/1.3/reference/frames.html

* Internet Explorer DOM Reference available at:
*

http://msdn.microsoft.com/workshop/author/dhtml/reference/dhtml_reference_entry.asp

* Netscape 6/7 DOM Reference available at:
* http://www.mozilla.org/docs/dom/domref/
* Tips for upgrading JavaScript for Netscape 7 / Mozilla
* http://www.mozilla.org/docs/web-deve...upgrade_2.html

[Brian Genisio]

Re: Browser to fullscreen - solution needed for many browser/platformcombina tions

Grant Wagner wrote:
[color=blue]
> Brian Genisio wrote:
>
>[color=green]
>>A requirement is a requirement.[/color]
>
>
> Yes it is, but it doesn't mean that the requirement flies in the face of
> everything known and understood about usability and the actual technical ability
> to accomplish the goal.[/color]

Sometimes, the requirement writers will want a feature that they know
goes against usability standards... and they want it anyways. (They
have the right to do this... they are paying for it) If it is
technically impossible, that is one thing, but if it can be done,
sometimes, it just has to be done to the way it was specified.
[color=blue][color=green]
>> The Boss wants it, there is little he can do to change his mind, other
>>than show the boss that it cannot be done. It is likely that the boss
>>will want it done as well as possible, even if only a few browsers are
>>supported. It is likely that the boss has seen it done before,
>>therefore knows it can be done, and cares little on the reasons against
>>it. Of course, there is nothing wrong with trying to convince the boss
>>against doing something like this, but I object to your method of
>>patronizing , condescending tone.[/color]
>
>
> There is a lot that can be done to change his mind.
>
> Design and develop a prototype of what he envisions. Then demonstrate it in the
> browsers where it works very well. He will not understand why you are arguing
> against the design when it works so well. *Then* show him the design in a
> browser like Firefox where the ability to resize or open new windows is
> disabled. Demonstrate that the look and feel of the site, even if it can be made
> to work in both browsers, will be a totally different, and possibly confusing,
> experience for the end-user if they switch between different browsers.
> Demonstrate that support will be an issue, because in browser A the screen looks
> like this and the controls are here and there, and in browser B, the screen
> looks like that and the controls are there and here. Explain how your help desk
> will, with different designs, have to determine *precisely* which browser an
> end-user is running and *precisely* how they have it configured before they can
> even begin to help someone having problems.
>
> Then demonstrate a different prototype. One that works flawlessly in every
> browser you show him. How it provide a consistent look and feel for the
> end-user. Explain how support (and development) costs will be much lower in the
> cross-browser design.
>[/color]

Prototypes cost time and money.
[color=blue][color=green]
>>The OP started off saying that he knew it was bad. You really don't
>>need to be such a jackazz about this. In your message you belittle the
>>OP and insult him/her. It is childish, and not needed here. The OP was
>>completely clear in his position, and is desperate for help. An answer
>>such as "It cannot be done because of X" is useful. Saying "Your
>>request is childish, unrealistic and disconnected" is crap. Calling the
>>OP a "bad, incompetent web author who is going to fail" is also crap.[/color]
>
>
> And your response offers the OP no assistance either. If you wish to help him,
> then help him. I would imagine you haven't helped the OP because you realize
> what a pointless and massive task it would be to develop two (or more)
> completely separate designs of the Intranet application he is developing to
> support the browsers that need supporting.
>[/color]

I did not need to give assistance. The correct answer was already
given. I was sick of heaing DU be as rude as he was. That is why I
posted. The OP appreciated it.

But, if the user base and environment is constrained, and the
requirements writers know this, the task becomes easier for the OP. If
the report is that it will only work with IE, then the people
responsible with the requirements can make a decision.

1. Do we want to only support IE?
2. Do we want to drop the requirement for full-screen?
3. Do we want full-screen in IE, but support others in non-full-screen,
even if it is confusing

That decision, is, ultimately up to the manager or the customer. It all
depends on what is more important to them, not the ideals of the
developer. There *are* valid reasons to take up the entire screen.
There *are* valid reasons for supporting only one browser. They may not
conform to normal usage scenarios, but that is fine, if the
*application* does not conform to normal usage scenarios.

All I hear is a bunch of close-mindedness about the way things _are_.
Sometimes, it is simply not true that the developer has a say in the
requirement. In theory, it should be so, but not always in reality.

Brian