|
|
(3 intermediate revisions by the same user not shown) |
Line 4: |
Line 4: |
|
| |
|
| ==Questions== | | ==Questions== |
| ===Q0: Shouldn't we agree that the main UX these days is web browser?=== | | ===Q0: Shouldn't we agree that the main UX these days is web browsing UX?=== |
| See [[Calligra/Usability_and_UX/Common/Startup/Startup_view_integrated_with_the_File_menu#Q0:_Shouldn.27t_we_agree_that_the_main_UX_these_days_is_web_browser.3F|"Startup view integrated with the File menu"]]. | | See [[Calligra/Usability_and_UX/Common/Startup/Startup_view_integrated_with_the_File_menu#Q0:_Shouldn.27t_we_agree_that_the_main_UX_these_days_is_web_browser.3F|"Startup view integrated with the File menu"]]. |
| | |
| | ==Mockups== |
| | *[[/Modern GUI of Calligra Words/]] |
|
| |
|
| ==Ideas== | | ==Ideas== |
Line 35: |
Line 38: |
| | Chapter 1 | Chapter 7 | <--- two tabs groupped as one | | | Chapter 1 | Chapter 7 | <--- two tabs groupped as one |
|
| |
|
| Random IRC log (jstaniek, boud, cyrille, sebsauer):
| |
| <pre>
| |
| [15:58] <boud> jstaniek: if you want to argue that our apps should work more like a website than a desktop application, maybe we should
| |
| get rid of the File menu completely and make the application look like a website, with a home button top-left _inside_ the window that
| |
| leads to a home screen where users can select actions.
| |
| [15:58] <boud> but that would look a lot like eclipse, I guess
| |
| [15:59] <boud> and maybe we should have a permanent search field that looks in all documents of the right type top-right, same to most websites
| |
| [15:59] <jstaniek> for the second thing: I am 99% sure
| |
| [16:00] <boud> or if a webbrowser is what you meant, not a website, when writing ""Q0: Shouldn't we agree that the main UX these days
| |
| is web browser?"
| |
| [16:00] <boud> put in a combobox with all recently opened documents with a search box next to it
| |
| [16:00] <boud> forward/backward buttons and a home button...
| |
| [16:00] <jstaniek> for the first: I did not expect anything calligra-wide, 1. it's up to maintainers, 2. new UX can be optional,
| |
| 3. simple apps like Flow or Braindump would play with the ideas easier than other apps.
| |
| [16:01] <jstaniek> boud: very interesting too
| |
| [16:01] <boud> is going to be tricky with split views, though tabs might be a good idea
| |
| [16:01] <jstaniek> boud: if the home displays recent docs and fav templates....
| |
| [16:01] <CyrilleB> well braindump does not have any open functionality... and new ui should not be optional, otherwise we lose consistence
| |
| [16:01] <boud> jstaniek: exactly
| |
| [16:01] <jstaniek> +1 for tabs
| |
| [16:02] <CyrilleB> for tabs... lets use window manager functionality
| |
| [16:02] <boemann> CyrilleB: +1
| |
| [16:02] <boud> The file menu can be what users expect from it
| |
| [16:02] <jstaniek> boud: speaking of browsers, opera is especially good at improved UX, eg. I bookmarked their previews-in-tabs at last akademy
| |
| [16:03] <jstaniek> y, the file menu or "Words" menu to be strict is the home 'page' also for the 'moder menu' proposal
| |
| [16:03] <boud> I always feel that opera is extremely cluttered and chaotic, but I haven't looked at it for a year now
| |
| [16:04] <boud> jstaniek: if you want to go for a browser L&F, the file menu should be a classic, old fashioned file menu and
| |
| not open the "home page"
| |
| [16:04] <CyrilleB> I though the trend for web browser was no menu ?
| |
| [16:05] <boud> Right. But my firefox still has one -- and that's what I was looking at.
| |
| [16:06] <jstaniek> boud: yes, the modern menu would be the page
| |
| [16:06] <jstaniek> i.e. moved
| |
| [16:06] <CyrilleB> but FF4 does not
| |
| [16:06] <boud> you can cut a lot of stuff from there though -- no reason to put settings or even the print dialog in the "home page"
| |
| -- especially since the concept of a home page in a web app means it's divorced from the active document
| |
| [16:06] <boud> CyrilleB: this is firefox 4.0
| |
| [16:07] <CyrilleB> hum, weird
| |
|
| |
|
| [17:56] <jstaniek> continuing the topic of UX, macosx introduces idea of dropping the save action completely | | *[[/IRC logs/]] |
| [17:57] <jstaniek> this plays ok with the browser paradigm
| |
| [17:57] <jstaniek> i.e. autosave
| |
| [17:57] <jstaniek> with nearly-indefinite 'revert'
| |
| [17:57] <jstaniek> action.
| |
| [17:58] <jstaniek> Of course kexi has no global save action by design (of the databases)
| |
| [17:58] <-- irina has left this server (Ping timeout: 246 seconds).
| |
| [17:58] <jstaniek> I seem to be convinced that the save action in document-oriented apps comes from old times
| |
| when the storage was on floppies (look at the icon..)
| |
| [17:59] <_anna_> jstaniek: sounds a bit like google docs editor
| |
| [17:59] <jstaniek> yes
| |
| [18:00] <jstaniek> _anna_: I'd love to see our opinions on that idea. Online editors have autosave for other reason (to avoid loosing
| |
| the work when user navigates out of the page), but autosave is useful regardless of using browsers.
| |
| [18:01] <sebsauer> jstaniek: guess a problem would be that saving a document can take some time... and auto-saving may block the whole UI.
| |
| So, it can not happen so often but then ppl may lose things on crash... idealy saving would happen in background
| |
| [18:01] <ahiemstra> oo does autosaving... and it blocks the ui
| |
| [18:01] <ahiemstra> which is horrible imo
| |
| [18:01] <sebsauer> or maybe even only save incremental... but that's way to hard to implement
| |
| [18:02] <ahiemstra> also, another thing with autosaving is that I may not want to save to the same document
| |
| [18:03] <ahiemstra> so unless you autosave to a backup file (which some calligra applications already do) you would get conflicts there
| |
| [18:04] <sebsauer> re save to another file; good point
| |
| [18:04] <sebsauer> jstaniek: how was that solved in macosx?
| |
| [18:05] <sebsauer> or maybe someone has to explicit SaveAs and just not edit the file if he really likes to save to another document?
| |
| [18:06] <ahiemstra> errr
| |
| [18:06] <ahiemstra> that's just horrible
| |
| [18:06] <ahiemstra> "hey, you edited the document so you I just overwrote your existing document which you did not actuall
| |
| want to write to, i'm sure you don't mind right?"
| |
| [18:08] <_anna_> it's a bit hard to learn new ways of doing things I guess
| |
| [18:08] <verbalshadow> sebsauer: not sure how MAC OSX solved it but inkscape does filename-Date-Time-group.ext and you can set the number of backups to keep
| |
| [18:10] <ahiemstra> the only way that would work properly is if you have proper versioning in all your files
| |
| [18:11] <ahiemstra> and unless we are going to force people to use git or svn with their documents that's unlikely to happen :)
| |
| [18:12] <_anna_> but my personal opinion is to use templates when a certain base structure is needed, not other documents (that can be made to templates when needed)
| |
| [18:13] <_anna_> but as said, people have their ways and the are stuck to them
| |
| [18:13] <ahiemstra> _anna_: you are talking about the startup related discussion right?
| |
| [18:14] <_anna_> no, I'm talking about using existing files as a base for new ones
| |
| [18:15] <ahiemstra> oh right
| |
| [18:15] <_anna_> though a bit slowly as I'm using my phone at the bus for irc ;-P
| |
| [18:16] <ahiemstra> well, the specific use case i'm thinking of is where i have some text document,
| |
| start reading it and making some corrections here and there and then realizing that I should save
| |
| it to a new version of the document
| |
| [18:20] <jstaniek> of course the autosave is together with ful lsave history, not just a single backup
| |
| [18:20] <jstaniek> mac also moved to that
| |
| [18:20] <jstaniek> sebsauer: ^
| |
| [18:21] <jstaniek> also I do not imaging it's the workflow that powerusers would like to switch in, say, kdevelop
| |
| [18:21] <jstaniek> _anna_: for documents, the idea of autosave is widely known (gmail, gdocs, wordpress, and most of the competing services)
| |
| [18:22] <jstaniek> so I am confident about level of familiarity
| |
| [18:23] <dmitryK> ahiemstra: you mean it won't work in all the compillers?
| |
| [18:24] <jstaniek> ahiemstra: no need to use VCS, we have discussion with Pau about this already; VCS are good for unstructured
| |
| objects like plain text files; there's nothing to optimize too in autosave on desktops
| |
| [18:25] <ahiemstra> jstaniek: then how are you going to save history?
| |
| [18:25] <jstaniek> (btw, if there's something to optimize, images and sounds: can be saved once and refernced). All that is detail.
| |
| [18:25] <jstaniek> to separate files
| |
| [18:26] <jstaniek> mac does so (with integration at the filesystem level)
| |
| [18:26] <jstaniek> i.e. file-level versioning
| |
| [18:26] <jstaniek> Nothing special at all.
| |
| [18:27] <sebsauer> jstaniek: then there is the problem that auto-saving can take lot of time with larger documents
| |
| [18:27] <ahiemstra> yes
| |
| [18:29] <sebsauer> maybe optimization would be possible there to not re-save e.g. images every time but still...
| |
| [18:30] <jstaniek> sebsauer: you know, hard to believe it's a problem. Browsers consume more CPU (even V8) and googledocs are useful.
| |
| [18:30] <jstaniek> I opt for reusing multicore of course.
| |
| [18:30] <jstaniek> We can do that; browsers: not that easy.
| |
| [18:31] <sebsauer> jstaniek: googledocs uses a db in the background. So, they just call UPDATE and voila. ODF is a bit more complicated there :-/
| |
| [18:32] <jstaniek> the saving process has 2 main CPU-intensive steps: 1. encoding the data structs to the ODF, 2. using the filter chain.
| |
| [18:32] <sebsauer> I mean incremental updates are not so easy in ODF
| |
| [18:33] <sebsauer> yes, so it can take way longer to save a document especially if you have images and what not
| |
| [18:33] <jstaniek> google docs use ODF-like doc definitions, since DOC is similar (i.e. not optimized for gdocs).
| |
| [18:33] <sebsauer> google docs actually uses an own xatom-like format. ODF is just for import/export | |
| [18:33] <ahiemstra> yeah, I was just going to say that...
| |
| [18:33] <sebsauer> so, it's not saved as ODF-files
| |
| [18:33] <jstaniek> Images, videos - all can be handled via resources, and we have them already. What I already like is that the
| |
| concept does not interfere with ODF requirements.
| |
| [18:34] <jstaniek> We need ODF for contacting with the outside world. Which is - different computer systems or calligra-unaware 3rdparty apps.
| |
| [18:35] <sebsauer> ah, you mean to not actually save to ODF but have something that allows incremental writes (e.g. SQLite).
| |
| Yes, would be an idea. But then you still need to write the ODF-file sometime cause that's what the user opened, no?
| |
| [18:36] <jstaniek> custom ODF-oriented apps use flat ODF XML for custom needs, and this breaks compatibility with apps requiring
| |
| structured ODF, but nobody complains as long as ther's veryeasy import/export path.
| |
| [18:36] <jstaniek> hmm no db, please :)
| |
| [18:36] <sebsauer> :)
| |
| [18:36] <jstaniek> can be surprising that _I_ do not promote databases, but really, serializing to tables degrades efficiency
| |
| [18:37] <sebsauer> but then you have the pribblem that saving can be rather expensive
| |
| [18:37] <sebsauer> problem
| |
| [18:37] <sebsauer> in terms of time needed
| |
| [18:37] <sebsauer> what means the UI freezes
| |
| [18:38] <jstaniek> I am assuming that we spend more time in CPU for playing with filter chains (eg saving ->ODF->DOC)
| |
| than with saving directly to ODF
| |
| [18:38] <jstaniek> I opt for a separate thread
| |
| [18:38] <jstaniek> we're prepared for that
| |
| [18:38] <jstaniek> since we have separation between data structs and the view
| |
| [18:39] <sebsauer> what sounds like lot of work for me to get it right. But yes, if that would really work then it could be done this way.
| |
| As long as we don't end with hard to debug code what can happen very easy using threads
| |
| [18:39] <jstaniek> delayed copying can happen to avoid blocking the structures that GUI uses, but this can be per-paragraph or so
| |
| [18:40] <jstaniek> sebsauer: I planed to continue the abstraction works by introducing value-based API for libodf
| |
| [18:41] <jstaniek> that would play with multithread
| |
| [18:41] <jstaniek> and not just in gui case but also in massive processing (that's why I though about Qt-only libs)
| |
| [18:42] <jstaniek> I have quite a bit of that done for Predicate, which has similar structures, e.g. full syntax tree for expression is value based now.
| |
| [18:43] <sebsauer> that (threads) sounds like a lotttt of work for me
| |
| [18:43] <jstaniek> libodf is built on top of a number of maps, it's quite typical system
| |
| [18:43] <jstaniek> introducing threads == 1. blocking or 2. delayed cloning
| |
| [18:43] <jstaniek> nothing more
| |
| [18:44] <jstaniek> the aim is to create a snapshot of the structures without global locks
| |
| [18:44] <sebsauer> I see. Still you need to synchronize if new content is added. Also I am not sure if it's really fast if you do a deep
| |
| copy of the whole QTextDocument
| |
| [18:44] <jstaniek> since saving (in a thread) means iterating over the structures, and accessing to global maps, the locks can be nicely atomic
| |
| [18:45] <jstaniek> a full copy is needed if you delete all the document while background saving has already started
| |
| [18:46] <jstaniek> in typical case saving happens while your system is idle, that's why I quite confident
| |
| [18:46] <sebsauer> actually we once had the idea to improve loading by using threads. But that was canceled then cause threads can bring
| |
| pain and there where easier ways to optimize
| |
| [18:47] <jstaniek> I beleive that was not about using background threads . That was about parallel computing. This is another story.
| |
| ODF processing is not easily parallelable...
| |
| [18:47] <jstaniek> (eg. because of cross-dependencies)
| |
| [18:48] <sebsauer> if you think you can do it then please do it. Personal I think it would be lot of work to get right.
| |
| But then maybe just deep copy a QTextDocument and/or setting locks at proper places would already do it. I've not really an idea there
| |
| how well our code and QTextDocument are prepared for that
| |
| [18:49] <sebsauer> but I know that I usually try to stay away from threads if not really needed ;)
| |
| [18:50] <jstaniek> yeah using threads without a good plan is like starting house renovation... you know :)
| |
| [18:50] <sebsauer> or helping others move from one house to another... yes, I know :)
| |
| [18:50] <jstaniek> good think is that the background savng would also be good for the classic behaviour
| |
| [18:50] <jstaniek> s/thing
| |
| [18:51] <jstaniek> i.e. for ctrl+S
| |
| </pre>
| |