Thread: [Screem-devel] shortcut bar question
Status: Inactive
Brought to you by:
davek
From: David A K. <da...@ri...> - 2003-12-09 18:06:13
|
I regularly swing backwards and forwards to if the shortcut bar should even be present in the UI. =20 For those who have read the development page on the web site (http://www.screem.org/development.html) I have mentioned possibly replacing it with a list view, like Rhythmbox have done, and along the lines of what Neutrino has. (http://neutrino.sourceforge.net/gfx/screenshots/catalog.png) This option is primarily just for a more consitant look with the rest of a desktop as shortcut bars are not very common. It still has many of the cons of a shortcut bar. Pros for shortcut bar --------------------- * nice large target to hit for switching views * nice large target to hit for switching sites * a bit more discoverable that multiple sites can be loaded at once * possible UI familiarity from Evolution, Outlook etc. Cons for shortcut bar --------------------- * takes up quite a large amount of space * No real advantage over just using the main menu as either views or sites is hidden at any time * can end up with a scrollbar which again results in items being hidden, and so not being faster to use than the menu. * complicates code for switching sites / views. Opinions, Comments, Suggestions? David --=20 Make your website SCREEM - Site Creating & Editing EnvironMent URL: http://www.screem.org/ Mail: da...@sc... |
From: Curtis C. H. <si...@co...> - 2003-12-11 00:35:20
|
On Tue, 2003-12-09 at 10:06, David A Knight wrote: > I regularly swing backwards and forwards to if the shortcut bar should > even be present in the UI. > > For those who have read the development page on the web site > (http://www.screem.org/development.html) I have mentioned possibly > replacing it with a list view, like Rhythmbox have done, and along the > lines of what Neutrino has. > (http://neutrino.sourceforge.net/gfx/screenshots/catalog.png) This > option is primarily just for a more consitant look with the rest of a > desktop as shortcut bars are not very common. It still has many of the > cons of a shortcut bar. I think there is a third option that i would prefer. I would like an option menu on the toolbar that lets me change the view, similar to the Nautilus file manager. I doubt this is faster than a menu, but it emphasizes the importance of the features the views offers. The HIG http://developer.gnome.org/projects/gup/hig/1.0/controls.html#controls-lists state that lists should not be used for less than five items. I hide the shortcut bar because I want more space for the editor. The smaller presentation of list items wastes more precious screen space. If there were more views to offer, I might keep the shortcut bar out all the time, but there are little I can think of that would make the list grow in the near future. Views: Validation I use tidy to validate, I would like to see a view that highlights bad markup GUI Editing Often requested, but I doubt I'll ever use it. Transformation Applying xslt on the fly to see the result. -- __C U R T I S C. H O V E Y____________________ si...@co... Guilty of stealing everything I am. |
From: Mark S. <ma...@hb...> - 2003-12-13 18:05:57
|
Hi all I'm often working on older web pages, wanting to simplify them using CSS and trying to shift them to the latest standards compliance. The validators that I've found on the net all seem to do a good job of telling me when tags are proprietary or deprecated, but they don't provide much in the way of helpful suggestions as to the current best practice that has replaced those old tags and techniques. I would really like to see an analysis capability built into Screem that would not only validate a page, but make conrete suggestions as to how to recode the page to be more correct. I don't know to what extent this might be automated. For example, use of a background colour tag in a table cell might trigger a wizard that offers a variety of more acceptable ways to achieve this effect using more modern HTML / XHTML and CSS. Or perhaps a wizard could walk one through the process of converting from TABLE's to DIV's. Anybody else feel like this would be useful? -- Try Debian Linux. Software freedom for the bold... See www.debian.org for more information. |
From: Curtis C. H. <si...@co...> - 2003-12-13 18:19:54
|
On Sat, 2003-12-13 at 10:27, Mark Shuttleworth wrote: > Hi all > > I'm often working on older web pages, wanting to simplify them using CSS > and trying to shift them to the latest standards compliance. The > validators that I've found on the net all seem to do a good job of > telling me when tags are proprietary or deprecated, but they don't > provide much in the way of helpful suggestions as to the current best > practice that has replaced those old tags and techniques. > > I would really like to see an analysis capability built into Screem that > would not only validate a page, but make conrete suggestions as to how > to recode the page to be more correct. I don't know to what extent this > might be automated. For example, use of a background colour tag in a > table cell might trigger a wizard that offers a variety of more > acceptable ways to achieve this effect using more modern HTML / XHTML > and CSS. Or perhaps a wizard could walk one through the process of > converting from TABLE's to DIV's. Anybody else feel like this would be > useful? I do. For the time being, I use tidy from tidy.sf.net as a helper validate: tidy -e clean+format: tidy -q -i -clean -wrap 0 -- __C U R T I S C. H O V E Y____________________ si...@co... Guilty of stealing everything I am. |
From: David A K. <da...@ri...> - 2003-12-14 20:52:39
|
On Sat, 2003-12-13 at 15:27, Mark Shuttleworth wrote: > I would really like to see an analysis capability built into Screem that=20 > would not only validate a page, but make conrete suggestions as to how=20 > to recode the page to be more correct. I don't know to what extent this=20 > might be automated. For example, use of a background colour tag in a=20 > table cell might trigger a wizard that offers a variety of more=20 > acceptable ways to achieve this effect using more modern HTML / XHTML=20 > and CSS. Or perhaps a wizard could walk one through the process of=20 > converting from TABLE's to DIV's. Anybody else feel like this would be=20 > useful? It would be a nice feature yes. I can see it being simple for things such as topmargin, leftmargin etc. but converting from table based layouts could be a very complex task depending of course on the complexity of the tables, if they are nested, use colspan/rowspan etc. Basic validation of tags is already performed by the tree view, although it doesn't like handling elements where the open tag is optional, e.g. <tbody> and so will display <tr> as being invalid in <table>. Extending this to include validating attributes is a very small task. I would presume the addition of a data file containing proprietary attributes/tags could be added which contained the information on alternatives, and then just perform a lookup while parsing the document. David --=20 Make your website SCREEM - Site Creating & Editing EnvironMent URL: http://www.screem.org/ Mail: da...@sc... |
From: Mark S. <ma...@hb...> - 2003-12-15 18:03:32
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> <title></title> </head> <body> <br> Does the syntax highlighting allow for setting the background colour around some text? Much like a highlighter marker pen? Perhaps that could be used... the proprietary tags could be background highlighted. That would not interfere with the foreground colour, used for the syntax, unless the colours happened to match ;-) With that in place, deprecated and proprietary tags could be spotted very quickly in the HTML.<br> <br> Next, rather than AI to help sort them out, it would probably be enough for a right click menu on those affected tags to include a "learn more" menu item, which would open a browser window on a page that we could write to address that specific tag. I'll commit to writing one or two such pages if the infrastructure is built.<br> <br> So a writer could look at a page, quickly seeing the offending tags. Right clicking on the deprecated tag would bring up the context menu, including a new item "Learn about deprecated tag XYZ", selecting this pops up browser on a page on the SCREEM website which discusses the tag and the best way to replace it with standards-compliant markup.<br> <br> Later on, for some of the simpler cases, it might be possible to have screem produce some recommended markup, but just pointers to the best practice info on the web would be a great start.<br> <br> <br> David A Knight wrote:<br> <blockquote cite="mid...@pc...work" type="cite"> <pre wrap="">On Sat, 2003-12-13 at 15:27, Mark Shuttleworth wrote: </pre> <blockquote type="cite"> <pre wrap="">I would really like to see an analysis capability built into Screem that would not only validate a page, but make conrete suggestions as to how to recode the page to be more correct. I don't know to what extent this might be automated. For example, use of a background colour tag in a table cell might trigger a wizard that offers a variety of more acceptable ways to achieve this effect using more modern HTML / XHTML and CSS. Or perhaps a wizard could walk one through the process of converting from TABLE's to DIV's. Anybody else feel like this would be useful? </pre> </blockquote> <pre wrap=""><!----> It would be a nice feature yes. I can see it being simple for things such as topmargin, leftmargin etc. but converting from table based layouts could be a very complex task depending of course on the complexity of the tables, if they are nested, use colspan/rowspan etc. Basic validation of tags is already performed by the tree view, although it doesn't like handling elements where the open tag is optional, e.g. <tbody> and so will display <tr> as being invalid in <table>. Extending this to include validating attributes is a very small task. I would presume the addition of a data file containing proprietary attributes/tags could be added which contained the information on alternatives, and then just perform a lookup while parsing the document. </pre> </blockquote> <br> <br> <pre class="moz-signature" cols="72">-- Try Debian Linux. Software freedom for the bold... See <a class="moz-txt-link-abbreviated" href="http://www.debian.org">www.debian.org</a> for more information. </pre> </body> </html> |
From: David A K. <da...@sc...> - 2004-01-22 03:16:58
|
On Thu, 2003-12-11 at 00:35, Curtis C. Hovey wrote: > I think there is a third option that i would prefer. I would like an > option menu on the toolbar that lets me change the view, similar to the > Nautilus file manager. I doubt this is faster than a menu, but it > emphasizes the importance of the features the views offers. I've just added an option menu to the toolbar, and I just don't like it at all. http://www.screem.org/viewswitch.jpg It just looks out of place IMO. I've also tried it shifted over to the far right, but that doesn't seem any better to me. I think Nautilus gets away with it as it is on the location bar toolbar, and so doesn't look as out of place, or possibly as the location entry expands to fill the toolbar. David -- Make your website SCREEM - Site Creating & Editing EnvironMent URL: http://www.screem.org/ Mail: da...@sc... |
From: David A K. <da...@ri...> - 2003-12-11 01:05:16
|
On Thu, 2003-12-11 at 00:35, Curtis C. Hovey wrote: > I think there is a third option that i would prefer. I would like an > option menu on the toolbar that lets me change the view, similar to the > Nautilus file manager. I doubt this is faster than a menu, but it > emphasizes the importance of the features the views offers. That is an option I hadn't thought of. Although it wouldn't cover the switching between open sites, unless two option menus were given, at which point I think the ui would be a bit cluttered. Then again switching sites probably isn't done very often so probably doesn't deserve a place in the toolbar. > The HIG > http://developer.gnome.org/projects/gup/hig/1.0/controls.html#controls-li= sts > state that lists should not be used for less than five items. I hide > the shortcut bar because I want more space for the editor. The smaller > presentation of list items wastes more precious screen space. yes, the idea was to have the loaded sites in the same list view, ala the neutrino screenshot I gave, which would push the number of items to 5 or more, but yes it does still waste space. David --=20 Make your website SCREEM - Site Creating & Editing EnvironMent URL: http://www.screem.org/ Mail: da...@sc... |
From: Curtis C. H. <si...@co...> - 2003-12-11 02:57:22
|
On Wed, 2003-12-10 at 20:05, David A Knight wrote: > On Thu, 2003-12-11 at 00:35, Curtis C. Hovey wrote: > > I think there is a third option that i would prefer. I would like an > > option menu on the toolbar that lets me change the view, similar to the > > Nautilus file manager. I doubt this is faster than a menu, but it > > emphasizes the importance of the features the views offers. > > That is an option I hadn't thought of. Although it wouldn't cover the > switching between open sites, unless two option menus were given, at > which point I think the ui would be a bit cluttered. Then again > switching sites probably isn't done very often so probably doesn't > deserve a place in the toolbar. hmm. Well putting sites in a sidebar is correct by convention, but I don't think you can mix the views with the sites. I'm doubtful that you will want to see a list of views under each site. I note that there is a trend in UI to move away from trees to have a simple list in both GNOME and MacOS. I think a list of sites and pages would be better than the icons. I stand by placing the view on the toolbar. -- __C U R T I S C. H O V E Y____________________ si...@co... Guilty of stealing everything I am. |
From: David A K. <da...@sc...> - 2003-12-11 01:18:56
|
On Tue, 2003-12-09 at 15:06, David A Knight wrote: > For those who have read the development page on the web site > (http://www.screem.org/development.html) I have mentioned possibly that should be http://www.screem.org/development.php David -- Make your website SCREEM - Site Creating & Editing EnvironMent URL: http://www.screem.org/ Mail: da...@sc... |
From: Mark S. <ma...@hb...> - 2003-12-16 19:31:24
|
>(http://neutrino.sourceforge.net/gfx/screenshots/catalog.png) This > > Looking at that pic, the best option to my mind for choosing the view (preview, editor, links etc) would be the "Artists Matching" swizzle button (I really don't know what the technical term is). This takes up little space on a toolbar, only takes up the space needed to show the current option, and quickly allows you to switch options. Now, as for the sidebar, there I would put the sites themselves. But alas I bring no code to the discussion, only hot airy electrons ;-) -- Try Debian Linux. Software freedom for the bold... See www.debian.org for more information. |
From: David A K. <da...@sc...> - 2003-12-19 07:16:11
|
On Mon, 2003-12-15 at 18:00, Mark Shuttleworth wrote: > Does the syntax highlighting allow for setting the background colour > around some text? Much like a highlighter marker pen? Perhaps that > could be used... the proprietary tags could be background highlighted. It does in theory, I've not looked into highlighting much since the switch to GtkSourceView. > So a writer could look at a page, quickly seeing the offending tags. > Right clicking on the deprecated tag would bring up the context menu, > including a new item "Learn about deprecated tag XYZ", selecting this > pops up browser on a page on the SCREEM website which discusses the > tag and the best way to replace it with standards-compliant markup. ah so something as simple as requesting www.screem.org/deprecated.php?tag=body&attr=leftmargin if a learn more item is selected. > Later on, for some of the simpler cases, it might be possible to have > screem produce some recommended markup, but just pointers to the best > practice info on the web would be a great start. with just a learn more system it shouldn't be too difficult to add, the syntax highlighting part being the most complex, but doable. David -- Make your website SCREEM - Site Creating & Editing EnvironMent URL: http://www.screem.org/ Mail: da...@sc... |
From: Mark S. <ma...@hb...> - 2003-12-20 16:51:08
|
>ah so something as simple as requesting >www.screem.org/deprecated.php?tag=body&attr=leftmargin if a learn more >item is selected. > > Yes, so we simply lead the author to "best practices" information which helps them figure out how to evolve their markup. -- Try Debian Linux. Software freedom for the bold... See www.debian.org for more information. |
From: David A K. <da...@ri...> - 2004-01-02 16:52:09
|
On Fri, 2003-12-19 at 07:16, David A Knight wrote: > On Mon, 2003-12-15 at 18:00, Mark Shuttleworth wrote: > > Does the syntax highlighting allow for setting the background colour > > around some text? Much like a highlighter marker pen? Perhaps that > > could be used... the proprietary tags could be background highlighted. >=20 > It does in theory, I've not looked into highlighting much since the > switch to GtkSourceView. this is now implemented in the CVS version, although with fixed colours. > > So a writer could look at a page, quickly seeing the offending tags. > > Right clicking on the deprecated tag would bring up the context menu, > > including a new item "Learn about deprecated tag XYZ", selecting this > > pops up browser on a page on the SCREEM website which discusses the > > tag and the best way to replace it with standards-compliant markup. The CVS version has a "Learn more" menu item. The main reason for this is that it can't be known if a tag is deprecated or not without hardcoding information about specific doctypes. There is currently a placeholder page setup that is opened in the a browser when the menu item is selected. > www.screem.org/deprecated.php?tag=3Dbody&attr=3Dleftmargin if a learn mor= e > item is selected. along with tag and attr the code is currently passing the PUBLIC id of the doctype in use. David --=20 Make your website SCREEM - Site Creating & Editing EnvironMent URL: http://www.screem.org/ Mail: da...@sc... |