Why? I'm a bit tired of the update window when I'm not updating. I prefer the current 'home node' interface of not including the update form when you are only looking (except I'd like "view above update form" after applying or for previewing an update). But I certainly don't see how either is "many many times better".
I'd rather see my nodes much closer to the same way others see them. For example, the big input box skews the display in none-too-subtle ways. The effect is particularly obnoxious when I'm working in a small window (but is annoying to me even when working in a huge window).
And the real problem with scratchpads is that they are fields in the 'user' record and they should instead be node types. Hacks and work-arounds are being done to sort of compensate for this when the effort should probably instead be toward fixing the root problem.
My original comment was a sideways dig at how "bolted on" scratchpads are. There are several poor user interface issues with them currently, only one of which was just noticed and has now been improved a bit (thanks, theorbtwo).
| [reply] [Watch: Dir/Any] |
tye:
I'm a bit tired of the update window when I'm not updating
I can't agree more! Now that I can edit a root node without changing the URL or clicking anywhere, the page is a whole lot longer (my CSS has a large textarea as when I'm editing I like to see a fair bit of what I'm typing)
... moments later, inspiration strikes ...
While I'm typing this it has just occurred to me, I'm quite happy to have textareas on the pages after all. (Sorry tye)
Now, this doesn't work in all browsers (IE for mac doesn't work; Safari does). But if you set your textarea CSS as below, textareas are tiny until focused. Once focused they 'spring open'. If your browser supports it.
textarea {
width: 400px;
height: 20px;
}
textarea:focus {
height: 400px;
}
Of course you can set your sizes to whatever you want, just experiment.
So, having done that, I can now just click into textareas I want to edit. When I don't want to edit I don't focus them and so they don't spring open.
"Get real! This is a discussion group, not a helpdesk. You post something, we discuss its implications. If the discussion happens to answer a question you've asked, that's incidental." -- nobull@mail.com in clpm
| [reply] [Watch: Dir/Any] [d/l] |
I guess the problem I see is that after you've edited your scratchpad, you have to stumbit it, wait for the server to accept it, then go view your scratchpad to see if you made a fiddly mistake. Even if I have a separate window open to the scratchpad, I find the process of stumbit, switch windows, wait, refresh, wait, and then see the effect to be obnoxious.
tye, I've often wondered why the Update form is there all the time; any reason not to just have the button that takes you to a displaytype=update view (which looks the way things are now, with both output and input, not the way displaytype=edit looks). | [reply] [Watch: Dir/Any] |
Ah. Your complaint was about not being able to preview nor automatically postview your changes. Yes, that isn't the best situation. But the best way to fix that for scratchpads is to first fix the underlying problem by making them separate nodes.
The only reasons to not remove the forms are the standard "they won't remove themselves" and "some people might like them" (if for no other reason than that they've become accustomed to them).
So I'm more inclined to avoid adding new always-there forms (not do what was originally requested) than to try to rip out all of the existing always-there forms (at least for now).
| [reply] [Watch: Dir/Any] |
| [reply] [Watch: Dir/Any] |
Then can't you put this link in your personal nodelet?
-QM
--
Quantum Mechanics: The dreams stuff is made of
| [reply] [Watch: Dir/Any] |
| [reply] [Watch: Dir/Any] |