View Single Post
Old 09-20-2011, 07:03 AM   #23
user_none
Sigil & calibre developer
user_none ought to be getting tired of karma fortunes by now.user_none ought to be getting tired of karma fortunes by now.user_none ought to be getting tired of karma fortunes by now.user_none ought to be getting tired of karma fortunes by now.user_none ought to be getting tired of karma fortunes by now.user_none ought to be getting tired of karma fortunes by now.user_none ought to be getting tired of karma fortunes by now.user_none ought to be getting tired of karma fortunes by now.user_none ought to be getting tired of karma fortunes by now.user_none ought to be getting tired of karma fortunes by now.user_none ought to be getting tired of karma fortunes by now.
 
user_none's Avatar
 
Posts: 2,487
Karma: 1063785
Join Date: Jan 2009
Location: Florida, USA
Device: Nook STR
Quote:
Originally Posted by itimpi View Post
Can be done in an incremental way. With a program that is as large as Calibre, and develops new functionality so rapidly any approach chosen has to fit in with the current Rapid Development methodology.
Changes don't have to be incremental. Typically when one or two big massive changes are started they're worked on in a separate branch. Once they get close to being finished they're integrated (if possible) into the main branch as a option. Some beta's are put out and tested by users. At this point the old functionality (if it replaces something existing) is removed and a new release is made with an incremented middle version number. This is how the 0.X majore releases are handled.

Quote:
Originally Posted by itimpi View Post
One should not assume that the current developers are UI design experts, so this may mean that someone who is good at UI desgn needs to become interested enough to actually start putting significant effort into the Calibre project.
100% true and I want to put emphasis on significant effort. You don't have to know how to code just provide mockups and rational. It's going to turn into an argument as to why you're changes are better but if you can provide clear and valid reasons as to why the changes are a functional improvement or at least don't remove functionality then they will be accepted.

So far most threads I've read with suggestions for improving the GUI have ened with:
  • The changes being platform specific (OS X only redesign).
  • The changes removing functionality.
  • The submitter not being able to provide as argument as to why the changes are a benefit.
  • The submitter not being able to handle criticism and storming off in a puff.

That said there is currently work to redesign the Web interface and it appears to be going well. It has significant UI changes. No one is opposed to changing the UI for the better but "it's ugly" honestly isn't helpful.
user_none is offline   Reply With Quote