Subject: Re: Try this css trick - msg#00065

Previous Message by Date: click to view message preview

Re: Composer CRAP

On 13.06.02 17:27, Justin H. Replied As Follows: --- Original Message --- > Jay Garcia wrote: >> On 13.06.02 00:23, Steve Keel Replied As Follows: >> >> --- Original Message --- >> >>> Michael J Gruber wrote: >>>> On 06/12/2002 04:10 AM, TuKo wrote:> Garth Wallace wrote: >>>> >>>>> >>>>>> Bamm Gabriana wrote: >>>>>> >>>>>>>> Anyone know of a GOOD wep-page design >>>>>>>> program? >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Notepad. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> emacs ;) >>>>>> >>>>> >>>>> vi :P >>>>> >>>> >>>> cat > a.html >>>> >>> >>> pencil > paper >>> >> >> Good one .... >> >> pico for me <unix newbie> >> > > vi is a great editor, as long as you have a command reference lying > around. One of my Linux books happens to have an entire chapter devoted > to vi, thankfully. :-) > > Justin H. > Yah, wellll ... When I switched from a Mac server to a Sun box running FreeBSD and Apache, it became a "learn it all over again" experience. PICO is a whole lot easier for me having to edit and create CRON files ... bah -- Jay Garcia - Netscape Champion Novell MCNE-5/CNI-Networking Technologies-OSI UFAQ - http://www.UFAQ.org ** Post To Group ONLY, do NOT email **

Next Message by Date: click to view message preview

Re: Tabbed Browsing?

Brian Heinrich wrote: Steve Rudman wrote: By the way, we've recently held usability tests of the Netscape help system and content, which is by and large the same as found in Mozilla (the help content in the Netscape version is more up-to-date). We did not encounter any users who contended that the help system is atrocious. I think David's looking at this from previous help-desk experience, and from that perspective, he's got a point. I haven't suggested that the help system and the help content couldn't be improved. But it would be great to get some real-world data about how the help system works or doesn't work. The Netscape Help Desk gets calls on a range of subjects, including those that are covered in help. But the vast majority of calls are about items that couldn't possibly be covered by help (e.g., crashed due to weird system configurations, and other idiosyncratic situations). I know anecdotally that the calls that come in for subjects that are covered in Help are from people who haven't tried to look in help---either they are oblivious that a Help menu can be used to navigate to topics that could help them immediately, or they so mistrust help systems in general that they are willing to shell out over $29 to have their questions answered. So, most of what we have is negative evidence, alas---we don't get as many calls on some subjects that we might expect to, so we have to assume the help is working for some people. Or no one is using a particularly complex feature. Or the UI is eminently clear. We're working on ways to gather feedback from users about the Netscape help, at least. We'd be happy to share that info, provided that it doesn't somehow compromise Netscape business/mktg interests (you know, THAT stuff). That has been the attitude of mozilla.org staff from way back---the Mozilla app does not need help content, though the help viewer is an open-source contribution to the overall app. Distributors can use the help system if they want or discard it. (I gave a talk about documentation at one of the early Mozilla developer conferences, before the help system was even in the app, and there was certainly eagerness among developers to have the help system as part of the Moz open-source effort, but no one wanted the help content in particular.) Mozilla is maturing; there are now people who are choosing to use it as their browser of choice. Providing a Help file that is helpful to the panicked and making other useful documentation available to them is no longer a luxury, I feel; it is a necessity. You can file this under the general rubric of 'marketing' if you wish. But marketing in this case extends well beyond Mozilla itself to include developers and OEMs as well as distributions based on Mozilla. Help content is a form of support. Distributors are obligated to provide their own form of support. Open-source efforts are often distinguished from their proprietary versions in that the latter have documentation and support. sendmail, for example, has 1000+ pages of documentation from Sendmail, Inc., whereas the open-source version of the software does not have that level of documentation. Part of the appeal of Red Hat's version of Linux is that it comes with documentation. And so on. Point well taken. Never the less, I fail to see how that somehow means that mozilla.org should not provide reasonably comprehensive and utile Help or other documentation. I'm not suggesting that mozilla.org should not provide useful documentation (sorry for the double negative, can't think fast enough to reword right now). I don't think mozilla.org is obligated to provide docs targeted towards end-users. I think there's plenty of work to be done, as a higher priority than end-user docs, in the way of developer docs. And "developer docs" includes stuff for hard-core programmers as well as website developers. My feeling is that there should be three levels of resources available for end users: Help, documentation on mozilla.org (which is admittedly not targeted at end users, but never the less . . . ), and n.m.u.*, with n.p.m.* for developers and others who are more involved in the project. I guess the question would be why you feel that Help isn't in need of some attention. Well, Help is in need of some attention, no doubt. But at the same time, there are probably other areas of documentation in need of attention. And Netscape is going to make another drop of their docs into the Moz tree, filling in some of the missing pieces. Soon. In the meantime, as you say (below) that the help is not well-organized, maybe an alternative proposal would help. Maybe what we need, in general, is a sort of "suggestion box" that exists on the website. There could be a page off of http://www.mozilla.org/catalog/end-user/, for instance, that categorizes the types of things that people raise in this newsgroup. People could submit their suggestions directly or someone in charge of a page (with some sort of tabular format) could enter the suggestions for new or revised content, or for structural changes, etc. Or we could have tracking bug for that. Or something that makes it easier to capture the info than searching through the newgroup postings. We could use the collection of suggestions for planning the next-gen of help. There are docs and then there are docs. Basic setup and installation docs I would expect for a program. But comprehensive, context-sensitive, task-based, instructional on-screen help is not somehow intrinsic to all programs. Arguing that help is integral to a program is a stretch. Most of us have the expectation that we'll get help along with a program, but we're used to the proprietary versions of software. And a paradox can always be paradoctored, right? ;-) It /is/ a browser suite, after all; documentation (Help or otherwise) doesn't need to be entirely comprehensive. And there are a number of resources that are otherwise available to users, which reduces the need for on-screen help somehow to be comprehensive, context-sensitive, &c. I'm not going to say that the on-screen help is atrocious; at worst, I'd say that it is at times unhelpful because not all that well organised. IMO, of course. Brian --Steve I think it's the right thing for a program to carry decent documentation, particularly with an interface as (hmm) disjoint as Mozilla's. I'd be interested to hear why you think it's a bad idea (and in what ways it's a bad idea) in more detail. Particularly as I'm one of those who is poking his head up to work on said help file ... Convince me I'm wrong :-)

Previous Message by Thread: click to view message preview

Re: Try this css trick

On 12.06.02 08:09, Richard Bozman Replied As Follows: --- Original Message --- > Add this to you forms for a nice effect alter colors to suit your needs. > > in the <head> area! > > <style type="text/css"> > input:focus { background-color: #FFF0F5 } > textarea:focus { background-color: #FFF0F5 } > input[type="button"]:hover { background-color: lime } > </style> > > -- > In/Outgoing mail is certified Virus Free by Norton 2002 anti-virus > system > > Richard's Web Page: http://bozman.net/family/index.html > Jannean's Web Page: http://bozman.net/glory/index.html > Rotty Cards: http://bozman.net/greeting/rottycard.html > Senior Rotty Register: http://bozman.net/family/senior.html > Rott-n-kids Webring: http://bozman.net/ringlink/index.html > Icq 1508821 Aim RBozie mailto:bozie@xxxxxxxxxx > > Doesn't work for me. Do you have a URL where this DOES work ?? -- Jay Garcia - Netscape Champion Novell MCNE-5/CNI-Networking Technologies-OSI UFAQ - http://www.UFAQ.org ** Post To Group ONLY, do NOT email **

Next Message by Thread: click to view message preview

HTTP headers

Is there a way to see all the HTTP headers (request and response) that are used to retrieve the current document? Is there a special javascript function to do this? Mattia