First, excuse me for invading the -dev mailing list with below "essay". Feel free to not read! :-)
Some thoughts about this thread. Is it so, that UX insight is a more rare and precious resource than strong programmers - from the perspective of Google Chrome? Sometimes, having something "already working" can make it much harder for a UX change to take place. Another reason for the core team to hold back Chris could be about project control. Than in effect publishing Chrome source is more marketing than open project, and it could be a good idea to fork Chromium? On the other hand, if the Chromium team wants happy non-google paid developers to be part of Chromium, you'd need to communicate more openly with them. Communicating is really hard and time consuming. A self-organising tree of the issues/knowledge shared or discussed could lower the hurdles. Some forums (phpBB) have superusers that move threads around and manually organise, but it really is a "search problem" ;-D. Chris G - you seem very ambitious, full of ideas and very probably a "strong coder". Since SVN handles Chromium source code, there are patch management tools that could allow you to keep your own patches parallell with the official source tree. It doesn't sound like they're too interested in your source, right? But surely you can make your small private fork and distribute your own Chromium flavor, that would have all the official features, plus some of your own. For an example, look at the German portable version (they use original binaries, but anyways). I don't have a problem re-learning, so I'd be happy to help testing your variation. Chromium has bug reporting, which in your own distribution should either be well-marked that it's not vanilla Chromium, or otherwise be disabled at least for now. Less than suitable on this list: * "Automatically add Search features from favourite sites." This should be valuable after the first import that is done just after installation of Chrome/Chromium. * "Set site to prefetch all links on page when loading for fast or offline access" Good for you, not considered polite towards web server owner. Most server owners pay for that bandwidth, you know! * Your complaints about the Page and Wrench-menus could probably be expanded a lot. Consider the Page - Encoding choice. When you've got a page with strange encoding, you probably need to try a few to find which works best. Or to find out that since the automatic recognition failed, so will you. (Otherwise = "search problem", meaning the auto- recognition needs more work!) * "why two buttons: Reload vs. Go." I agree. A button "Load" could cover both needs! I'd prefer Load to replace Go on the right. Clicking "Load" when you have already loaded a page probably means reload this URL (user on a chat/forum site, or a web developer) or possibly that you want to start over with filling in a form. In some rare occations (e.g. using IE) you might run into a javascript error shuts off all further javascript-processing and killing the application. Then you reload the page to revive the javascript, and possibly loose form filled data! (The latter should probably be handled with a top-bar asking "Re-fill form?", but that's getting into form-filling which isn't my expertise - I don't use roboform and I which I never have to, but whishing hasn't yet made OpenID, YADIS, etc mainstream) Reloading without cache is usually done by shift- or control-clicking on reload, but either doesn't work or works half-way in Chrome. It doesn't for instance re-check a 301 Permanently moved -- not even when I type the URL as view-source:http://... * View-source: Seriously bugged -- and should be easy to at least improve! For starters, don't call source tabs "Noname", but make it "Source of http://..."; or similar! If I knew somebody who can compile me a binary, I'd do some source digging and supply that person with a tentative source code patch! :-) (Further view-source bugs are probably in the Chromium bug tracker.) GOAL 4: "I will also need a way to edit the backend data (doesn’t need to be pretty)." I guess backend uses SQLite - so look for tools for that. I saw some blog post about digging into Chrome history etc. using SQLite tools. Bookmarks It seems you really use them, and I'm sure most people do. In the last few years, I've really never used bookmarks like they're intended to. Before Chrome, I used Firefox and bookmark=on my to-read list, deleting them as I go. Then I found "Read it later" and stopped using regular bookmarks. Sometimes I used a Google Bookmarks plugin to mark sites I wanted to find again easier, a trend that started by using del.icio.us (via Flock) and I now use Chrome stars/bookmarking to ensure those sites come higher up in an omnibar search. But I very rarely use such bookmarks to-be-findable later, and the few times I really need to get back to some site I rarely find it again! Have you considered, that if you know something (name, part of url) to a bookmark, you could just type it in the omnibar instead of using your eyes+brain search engine? It requires a bit of getting used to -- finding something that you CAN see is easier than the omnibar type-and- try, and that's why keyboard shortcuts are allowed to take up space in menus. But with more visible bookmarks it seems too expensive in screen use and distraction potential. By the way, are you doing "patrolling" of mail accounts, stats-pages, etc and for that you need bookmarks that you can organise? Have you considered Netvibes or other sites that allow you to collect/organise bookmarks? Or build your own hybrid of Netvibes and Stumble-upon's "Next" -button, to help you step through you "patrolling" tasks! I'd never accept patrolling "manually" myself, since it can be automated. Push instead of pull. I have all my 2 needed email accounts forward in to my one GMail. Because of this, I don't want bookmarks to be tied to the browser, but rather be an addon or service choice. Maybe offline/online syncing web service, maybe reusing the "service" concepts from Flock. I doubt there is a UX that fits both you, me, Google's visionaries and the typical IE user (who, by the way, doesn't use Chrome yet). If those guys let you, and other strong coders, too near the Chromium project, I bet Chromium would turn out to be "by coders, for coders" - sorry, but then go build Firefox 4 instead! That's a "for coders" product. By the way, I have some ideas of my own. If you can't see the need or why they are better than how it's done in all current browser (aren't they stupid? :)) then that could be a clue as to why some others don't realise why your needs and ideas are the best available and deserving of immediate further discussion. History Since tabs came along, I no longer use window-local history (context or long-click on the Back button). Sometimes I click Back once, but mostly I always open new tabs and close old ones. That way I see in the tab bar how old they are. Right now one page from "The Omni Group" is stuck in the left corner, telling me I soon better choose between not reading it, or moving it to a Read it later-list :-). Sometimes I close a tab and un-closing a bunch of tabs until the wanted one comes along might be tedious. A more fancy, and maybe possibly better UX, browsing history could be shown as a tree. I'm imagining something like http://github.com/aslakhellesoy/cucumber/network with each row showing one window. I could then track separate Chrome windows. The top row (aslak) having one line for each tab (right now I see three of them). And the name on a row being maybe date,time when I opened that browser. This could be expanded (as so often is the whish of a coder!)... eh.. yes expanded to show statistics on how long time I spent on each page. Hovering a dot (node) would show thumbnail, and those statistics. But these features are too "fat" and too non-mainstream that it'd have to go in an addon or possibly a userscript paired with a web service. Maybe some of your needs could be covered as userscripts? There is already two implementations. I also seem to perceive that you really want to become integrated in a/ the Chromium developer community. I've since long decided it's not really what the core group wants or has time/qualifications to achieve, so sorry but I think you could stop bugging them for attention. It would be great to have an active coding community available to _outsiders_ though, so maybe forking Chromium is worth a try? I'm actively watching the mailing lists for "outsiders" with both initiative and skills, and the people are lacking. So far, you and that guy doing a browser component (Marshall Greenblatt) are the only two I've noticed. I have some ideas, but lack of skills and time to set up the build environment and code anything on my own. My sketches and notes so far (and a small GUI makeover!), but excluding the ideas above: http://sites.google.com/site/chromiumdev/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Chromium-dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~----------~----~----~----~------~----~------~--~---
