Plasma/Active/Development/TaskCentricIdeaMinutes
UNDER CONSTRUCTION Meeting minutes for the brainstorming meeting on the topic of a task-centric approach for Plasma Active
Date: 2013-01-16, 19:00-21:00 CET
Location: Freenode, #active
Participants: Aaron Seigo, Carl Symons, Marco Martin, rubentje1991, Shantanu Tushar, Thomas Pfeiffer
Meeting goal: Fleshing the ideas created during the brainstorming meeting out further, including the technical perspective.
Raw log:
[19:15:09] <notmart> ok, so, very very brief recap then start [19:15:18] <colomar> Okay [19:15:29] <notmart> conclusion last time was still quite abstract if i remember correctly [19:16:11] <colomar> In essence: What we want is a system which supports a combination of optimized UIs for different applications including document templates and other data to ideally support specific tasks [19:16:21] Quit mck182 has left this server (Remote host closed the connection). [19:16:26] <colomar> For that we need: [19:16:44] <colomar> A set of commonly used tasks [19:16:44] <colomar> Tool building blocks, as many and as atomic as possible [19:16:44] <colomar> A UI to connect the blocks to form a task workflow [19:16:44] <colomar> A way to share / get them [19:16:44] <colomar> A tool to easily create new UIs from templates [19:16:44] <colomar> A way to start a task with given parameters [19:17:09] <colomar> What we need very soon is at least one way to start a task [19:17:47] <Shaan7> maybe the dialog which pops up after you click the "+" button has a section called "Create" [19:17:50] <colomar> The idea was to define an example task and create a tool to support that task [19:18:25] <colomar> Shaan7: That is something I had in mind as well. It only works for tasks which involve creating resources, though [19:18:31] <colomar> But I think we should have that [19:19:04] <colomar> Okay so I think at first we should define what we want to have when, so that we cvan prioritize [19:19:05] <notmart> i was more thinking of something that looks similar to the addons store [19:19:48] <Shaan7> well I'd envision something functionally providing atleast an equivalent to the "Create New" context menu in Dolphin [19:19:49] <colomar> notmart: We could have both. I think a button to start a creation task in the Add Items dialog makes sense as well [19:19:58] <kallecarl> discussed task-centricity rather than application [19:20:19] <Shaan7> yep so no PA application should have a dedicated UI to create new stuff [19:20:28] <notmart> but, you could try to describe an user scenario, maybe it makes ring some beels about how an implementation could be [19:20:54] <colomar> Okay, one example we came up with during the last meeting was the following: [19:20:59] <Shaan7> email? [19:21:09] <kallecarl> +1 - have to start with use case [19:21:19] <colomar> A user is in a meeting. Either she has already created an Activity for that or just an event in her Calendar [19:21:21] <notmart> one thing i am a bit hesitant about the add resources ui, is that the shell is quite huge already [19:21:35] <notmart> i don't know if i want to add any more complexity anywhere near it [19:21:57] <colomar> Now she wants to take notes during the meeting and save those as an ODT file [19:21:58] Quit fabian has left this server (Quit: Konversation terminated!). [19:22:10] <kallecarl> err save as a file [19:22:14] <kallecarl> maybe [19:22:23] <Shaan7> save as a document, rather ;) [19:22:58] <colomar> Shaan7: Of course from her point of view, it's just "A text document". She doesn't care about ODT of course ;) [19:23:00] <kallecarl> anyway...save notes for some purpose [19:23:06] <colomar> Yes [19:24:02] <kallecarl> colomar: what then? keep an archive, distribute notes, refresh her memory later? [19:24:59] <colomar> In that case, there should be a note-taking task which starts Words Active with a very minimalistic UI and the template she typically uses for note-taking with the date and meeting title pre-filled from the event [19:25:29] <Shaan7> hmm alongwith tasks, the applications should be able to take contextual info as well [19:26:05] <colomar> When she has finished the document, it should be both attached to the event and Activity and she should have the option to send it to the other meeting participants automatically [19:26:36] <kallecarl> Shaan7: in other words, person is in a meeting and wants to write. task centered capabilities takes care of the details without person needing to specify: [19:26:53] <kallecarl> application, storage location, later access requirements [19:27:30] <Shaan7> hmm and "later access requirements" is achieved by attaching it to the current activity? [19:27:52] <kallecarl> don't know "how" yet, just trying to get the user scenario [19:28:01] <colomar> Yes. And it should be associated with the event in Nepomuk [19:28:25] <kallecarl> gets complicated...what about if person wants to write a topical email? [19:28:31] <colomar> The whole workflow should be done without the user ever having to manually start an application [19:28:34] <kallecarl> still writing, but also connecting [19:28:50] <kallecarl> actually writing + sharing [19:28:59] <kallecarl> +connecting [19:29:07] <colomar> That's what SLC is for :) [19:29:11] <kallecarl> yeah [19:30:43] <Shaan7> hmm [19:31:05] <colomar> So we need something that starts the applications and provides additional information [19:31:38] <Shaan7> and that something should be easy to access, maybe alongside the SLC icons [19:31:38] <aseigo> wrinkle: if the person starts a document (say, a spreadsheet) and we want associated with the activity ... [19:31:48] <colomar> And the applications need to be ready to use that info to adapt accordingly [19:31:50] <aseigo> ... we need an entry on disk, or at least in nepomuk, to make that association [19:31:55] <kallecarl> so what's needed is a good definition of this example user scenario, and then exploration of how to implement given current or doable capabilities [19:32:35] <aseigo> if we make that entry and then launch the application .. and then the user changes their mind and decides not to save anything, we end up with an empty file and an empty (no value) association with the activity [19:32:37] <notmart> have some concerns on the idea (and also like it, it other parts) [19:32:49] <aseigo> if we don't create the item right away, then we rely on the application to do this [19:33:12] <Shaan7> let the app do it, i'd say [19:33:17] <notmart> i think the danger here is falling in the temptation of building some sort of "omnicomprensive" thing that lets you do all [19:33:17] <aseigo> this is not a big problem, but i think it may say that we need some support in applications to really make this seamless. [19:33:30] <kallecarl> aseigo: ys [19:33:31] <kallecarl> yes [19:33:33] <notmart> just as a general thing of the usual advice of "keep it simple" ;0 [19:33:52] <kallecarl> writing document has different characteristics from spreadsheet document [19:34:03] <kallecarl> but those can be distinguished [19:34:12] <aseigo> we can provide a class / QML component that encapsulates all that quite nicely for the application .. but then we need a standardized way of launching an application in a way that triggers that [19:34:17] <kallecarl> still something is needed at the app level [19:34:25] Quit Sho_ has left this server (Quit: Konversation terminated!). [19:34:31] <notmart> as implementation, for tasks that are creation of a document, probably it will have to be : user says create -> asks the name -> saves on disk -> adds in nepomuk -> associates with activity [19:34:32] <colomar> notmart: Yes. I prefer to paint some unicorns on the wall first and then do the reality-check, though, instead of limiting ourselves form the start [19:34:50] <aseigo> put another way: once the person has launched something, we also need the application to help us out to do the connecting bit [19:34:57] <Shaan7> notmart: or, when possible, tries to guess the name from context [19:35:09] <notmart> created either with some command to the application (parameters or commandline tool) or copied from a template file already existing [19:35:29] <aseigo> so when we design out the implementation, let's keep that in mind... [19:35:40] <notmart> Shaan7: that too, even toughnot sure how much context we can have besides activity name [19:35:41] <aseigo> colomar: did you have any ideas of at which point the person gives their new "thing" a name? [19:36:13] <rubentje1991> context: location from gps? [19:36:15] <colomar> aseigo: I agree with Shaan7 that we should use context to suggest a name [19:36:16] <Shaan7> notmart: yea but atleast that (plus other stuff like date/time) can serve as a default and the user can choose to change it [19:36:34] <notmart> yes [19:36:39] <Shaan7> detecting more context can be more complex, but lets keep that as a possibility [19:36:40] <kallecarl> aseigo: interesting point, Wittgenstein would say that naming it brings it into existence [19:36:57] * aseigo would agree ... [19:37:06] <kallecarl> you and Ludwig...like that [19:37:09] <colomar> That should happen at the point where it's actually saved. In the meeting note case, something like "Notes for event "<title>" on <date>" could be suggested [19:37:15] <aseigo> here's the rub with that .. (to keep throwing sticks in our path ;) [19:37:22] * Shaan7 has always wished Nepomuk to give us a nice "no-filesystem" Save dialog. trueg used to blog about something like a long time back [19:37:30] <aseigo> it's sometimes hard to come up with a name before you start creating it. you may also want to change it later. [19:37:44] <Shaan7> aseigo: thats easy no? just let the Files app have a rename option [19:37:47] <aseigo> Shaan7: his attempts were well meant and interesting, but overly complex imho [19:38:09] <Shaan7> hmm, I remember very faintly though [19:38:11] <aseigo> Shaan7: that's ugly though imo.. because then you need to find it, which implies leaving the creation app [19:38:27] <aseigo> what would be truly awesome for myself personally is the ability to rename it whenever i wanted [19:38:33] <Shaan7> ah by later you mean not that late when the app is closed [19:38:52] <aseigo> right, i might open a new text document and call it "plasma active meeting" [19:39:09] <aseigo> and then 20 minutes into it realize i'd rather call it "new document workflow notes" [19:39:18] <colomar> Do we really need to create the file before the note-taking is done? [19:39:20] <Shaan7> hmm but thats only possible if the app provides that support, isnt it? [19:39:29] <Shaan7> colomar: yes, what if the device goes boom! :P [19:39:38] <kallecarl> colomar: need to know that the file is going to be retained [19:39:38] <Shaan7> with the SSD being intact, that is [19:39:40] Nick trueg is now known as trueg_away. [19:39:52] <aseigo> colomar: no; and in fact we can't always .. so that's why the app must do the connecting for us as well [19:40:06] <colomar> I'd prefer to ask for a name when the meeting is over and the user wants to complete the note-taking task [19:40:09] <aseigo> Shaan7: yes .. perhaps ... [19:40:31] <colomar> Maybe create the file with a dummy name and then rename it when the user has finished and knows the name? [19:40:36] <Shaan7> aseigo: what communication we need from the app? we just need to tell it "hey, create a document of this type with this title and show a nice UI to the user", right? [19:40:46] <rubentje1991> first a temp-name, later a definite one... or more focus on tags? or file properties? [19:40:47] <aseigo> colomar: is that always at the end? [19:40:49] <notmart> well, the app can save a temp file somewhere not seen by the user, that's another detail [19:41:15] <aseigo> Shaan7: not even that really ... just "here's my document i created, please connect it to whatever it needed to be connected to" [19:41:18] <colomar> We've imagined the tasks as rather small, clearly-defined ones, not like "Writing a dissertation" [19:41:20] <notmart> only thing, if we save it later, we're again at the problem of having some sort of save-as dialog [19:41:22] <aseigo> in a way, it's a bit like an automated SLC [19:41:28] <Shaan7> aseigo: by whatever you mean some activity? [19:41:33] <aseigo> Shaan7: yes [19:41:36] <aseigo> (as one example) [19:41:41] <Shaan7> okay [19:42:26] <aseigo> colomar: or maybe drawing a quick diagram in krita [19:42:28] <kallecarl> Shaan7: could be other than some activity too...e.g. person's name or company name mentioned in the writing [19:43:02] <colomar> aseigo: Yes. We also need a way to start a sub-task from within another one [19:43:04] <aseigo> so for me (from an implementor's POV :) what i'd like to sort out is: [19:43:09] Quit jpwhiting has left this server (Quit: Konversation terminated!). [19:43:17] <aseigo> a) what the "starting point" UI looks like and can be responsible for [19:43:24] <aseigo> b) what the application needs to help out with [19:43:50] <aseigo> c) what other cool things we'll leave up to the user to handle (e.g. tagging it with things like the company name or a contact via SLC) [19:44:23] <aseigo> notmart: oh, which reminds me, i've been thinking more about SLC and have some thoughts i wouldn't mind discussing with someone soon [19:44:27] <aseigo> (not now though of course :) [19:44:31] <colomar> Yes. Though the "starting UI" is more like a "meta UI", because it also needs to pick up after one application's sub-task is done and the next one starts [19:44:50] <notmart> aseigo: even right after the meeting is over is fine ;) [19:44:50] <Shaan7> colomar: didnt understand that one [19:44:51] Quit mbolo has left this server (Ping timeout: 248 seconds). [19:45:05] <aseigo> colomar: that's interesting indeed. hm. [19:45:13] <notmart> sub-task, hmmmm [19:45:14] <aseigo> colomar: and will absolutely require one of two things: [19:45:14] <colomar> Shaan7: A task may consist of several applications [19:45:17] Join AlmAck has joined this channel ([email protected]). [19:45:27] <aseigo> a) application communication: "Ok people, I'm done" [19:45:48] <aseigo> b) process tacking (e.g. by PID) and rely on "application quit == do the next step" [19:45:51] <notmart> problem is when i think about stuff like that, i can't help but think to a system/ui that becomes kinda "bureaucratic" [19:45:57] Join jpwhiting has joined this channel ([email protected]). [19:45:57] Quit jpwhiting has left this server (Changing host). [19:45:57] Join jpwhiting has joined this channel (~jeremy@kde/developer/whiting). [19:46:00] <notmart> and people don't like that ;) [19:46:20] <aseigo> notmart: if it's done well i don't think it will come across like that [19:46:42] <colomar> Yes. It's something we need to keep in mind to avoid it, but that's doable [19:46:44] <Shaan7> errm this sounds kinda complicated :/ [19:46:50] <notmart> yes, in the end there should still be at least an "illusion" of total freedom [19:47:04] <kallecarl> in reality, there is a limited (and I'll say small) number of things that person will be doing at THIS location and at THIS time and in THESE contextual variables [19:47:18] <aseigo> what would be utterly sick would be to go into the ui and by pressing options build "sentences" like: "create a drawing" -> "and send it by email" -> "to grandma" [19:47:27] <kallecarl> sick is good [19:47:51] <aseigo> "take notes" -> "saved to my device" [19:47:52] <colomar> notmart: Yes, and customizeability as well. In Björn's vision, users can modify or create new tasks themselves rather easily [19:48:00] <notmart> aseigo: more as in navigating a menu or by writing sentences/commands? [19:48:15] <aseigo> notmart: neither :) pick from a set of options [19:48:17] <aseigo> SVO [19:48:51] <aseigo> subject verb object ... a syntax of sorts ... where the first set of options is what to make [19:49:08] <colomar> And we can use all that context stuff we have for the recommendations here [19:49:30] <aseigo> once selected you can select the "do it now" (or "saved to my device") option at the top of the next set of options ... [19:49:39] <colomar> This may be one way where the recommendation engine can become really useful [19:49:45] <notmart> eh, in reality all that exists here is most opened files not in activity yet... that's pretty much it ;) [19:50:07] <Shaan7> uh oh, now thats sounding like a grammar class :P [19:50:08] <aseigo> and if you pick "send by email" then you get a list of contacts to pick from or a "choose recipients later" .. and them voom [19:50:14] <colomar> hm, but what about the named locations and all that stuff? [19:50:29] <notmart> ah, yes, there are named locations [19:50:38] <colomar> aseigo: Yes, and in the meeting case the meeting participants are suggested [19:50:45] <notmart> and activities rated in relation to the locations [19:50:52] <aseigo> nice thing about a simple grammar like that is it can be contextual, modular and saved as "sentences" for one press workflows if they are common [19:51:00] <aseigo> (either as presets, or because the user wants to do the same thing again) [19:51:28] <aseigo> "Make a diagram and post it on google+" [19:51:33] <aseigo> colomar: yes, we can pull from contacts book + activity associations [19:51:49] <colomar> Yes. [19:52:11] <aseigo> CSLC -> create, share, like, connect :P [19:52:36] <Shaan7> ... [19:52:47] <kallecarl> and doesn't have to be a sentence strictly speaking...could be touch gestures...circle the item, keep finger down, circle item2, pull to connect location [19:52:51] <aseigo> colomar: do we have visual mockups, btw? [19:52:54] <colomar> The grammar could indeed be useful for creating tasks. Our idea in the last meeting was that users have a repository of common tasks (either created by them or by other users) [19:53:16] <colomar> aseigo: Not yet. That would be the next step on the design side [19:53:18] <aseigo> kallecarl: yes, doesn't have to typed at all. i'd hope not, in fact. touching options would build the sentence [19:53:26] <Shaan7> our problem is what exactly is a task, implementation wise [19:53:30] Quit blaroche_ has left this server (Quit: Konversation terminated!). [19:53:41] Join rcg has joined this channel (~rcg@2a02:908:e250:8401:99a6:6d9d:d1c7:5e80). [19:53:43] <notmart> aseigo: still don't understand how you would make the selection of the proper subject, then verb etc look/work... [19:54:08] <notmart> so it still "looks" like a menu navigation [19:54:32] <colomar> notmart: Or more like a chain of building blocks [19:54:37] <aseigo> notmart: in the most trivial type of implementation ... imagine a list of all the kinds of documents you can create shown on the screen. maybe looking like the files app presentation. [19:54:42] <aseigo> you pick "image" [19:55:11] <aseigo> and now we have "Create an image..." shown somewhere (perhaps picking "image" causes that item to animate to where the sentence gets built?) [19:55:33] * aseigo notes that he's making this hard for translators, but will ignore that for a moment :P [19:56:06] <Shaan7> +1 for the something similar to the files app [19:56:11] <aseigo> and now you get shown a set of options, based on what's possible with an image on the device -> saved to device; sent to owncloud; posted on google+; sent by email [19:56:13] <notmart> hm, so not too different to my first idea about it, and i said "menu navigation" because i pictured it looking not much like the files app, but more like the addons app [19:56:20] <aseigo> you select one or more and that builds out the "sentence" [19:56:24] <colomar> aseigo: Yes, that's what I have in mind as well. The different blocks moving to a place where the sentence is formed [19:56:29] <aseigo> notmart: that could also work [19:56:34] <aseigo> colomar: yea :) [19:57:08] <aseigo> each block would represent another step in the processing pipeline ... now managing that pipeline, knowing when each step ends .. that's where the implementation bits about application cooperation comes in [19:57:22] <colomar> I think this and notmart's idea with the columns could both be nice [19:57:29] <aseigo> because perhaps i start an image to post to google+, but then change my mind and don't finish it [19:57:41] <aseigo> colomar: yeah, either would work out imho [19:57:45] <notmart> in that case, the list of the selected items in the columns is the phrase [19:57:58] <aseigo> notmart: yes... [19:58:20] <aseigo> the only hesitation i have with columns like that is i may wish to do multiple things with it [19:58:29] <rubentje1991> yep, is important [19:58:34] <notmart> yeah [19:59:05] <rubentje1991> but multiselect is an implementation issue I think [19:59:08] <aseigo> save it to device, send it by email .. i may want to make a picture, then arrange it in my local photoalbum app, then post it online [19:59:50] <rubentje1991> that would be a good starting workflow example [19:59:53] <rubentje1991> in my opinion [20:00:00] <aseigo> because it's hard? ;P [20:00:10] <notmart> could well be represented a list of do this then do that then this other.. [20:00:14] <aseigo> but yeah, it's not completely unrealistic [20:00:20] <aseigo> notmart: right .. [20:00:28] <notmart> just keep presenting the list of available actions once one is selected [20:00:29] <aseigo> you have the "thing" you're making, then what you want to do with it [20:00:47] <notmart> eventually narrowing them down if a precedent choice made some actions not possible [20:01:00] <colomar> notmart: yes [20:01:13] * aseigo notes that in an SVO language, the "thing" gets named last [20:01:20] <colomar> And also offer suggestions at each point based on context [20:01:35] <aseigo> (which may be a hint to "when do we name it") [20:02:24] <aseigo> going bak into implementation mode ... we always start with what kind of thing we want to create? [20:02:40] <aseigo> if so .. then we can link actions to file types as a first filter [20:02:40] <Shaan7> yep [20:02:43] <notmart> aseigo: then after one chosen all the stuff to do what would happen? it would need to tell applications what to do, maybe even more then one, maybe with a dependency chain... [20:02:49] <colomar> We don't necessarily always create things [20:02:55] <aseigo> notmart: yes, that's the implication [20:03:07] <aseigo> colomar: example? [20:04:02] <kallecarl> could also be diagrams ... a la http://scratch.mit.edu/ [20:04:32] <colomar> find me the ideal mode of transportation to get from here to my meeting, then navigate me and play a videeo to keep me entertained during the trip. And if I may be late, call Peter [20:05:22] <kallecarl> colomar: exactly the kind of example I use when presenting PA [20:06:16] <colomar> That's totally unicorns at this point, but it's Something I'd love to have. Just fire that up and you're fine, nothing more to do [20:06:34] <notmart> so it would kindof create a "script" that does stuff [20:06:52] <notmart> almost remembers me the apple automator thing [20:07:56] <colomar> notmart: As long as they haven't patented the whole general idea yet, that sounds like a good thing ;) [20:08:34] <colomar> I guess the majority of tasks will probably be about creating stuff, but the system should be flexible to allow non-creating tasks as well [20:09:05] <kallecarl> colomar: not necessarily...fetching stuff too [20:09:19] <colomar> absolutely [20:09:44] Join felix_ has joined this channel ([email protected]). [20:10:03] <colomar> All Active applications should have the hooks necessar to launch them with given parameters and geed their status when they're finished [20:10:08] <colomar> +y [20:10:35] <colomar> geed = get (what was I typing???) [20:10:35] <Shaan7> what status will they give back? [20:10:59] <Shaan7> lets say Words, what will it return as a status when i'm done writing my text document? [20:11:29] <aseigo> hopefully at the end of its process it should be able to say "i'm finished, and the content can be found <here>" [20:11:42] <colomar> yes [20:11:52] <aseigo> btw, this is sounding more and more and more like a scripted SLC [20:11:54] <Shaan7> we need that to, lets say associate with the activity? [20:12:00] <notmart> as reference, the thing that made me remind, automator, is basically a ui for building flow charts for actions to do, it generates a script that can lauch application and invoke ipc similar to dbus to make the applications do what it's scripted [20:12:16] <aseigo> notmart: yeah, was thinking of that too [20:12:18] <kallecarl> notmart: so they stole ideas from MIT [20:12:29] <kallecarl> and patented them prolly [20:12:37] <notmart> kallecarl: their usual workflow no? :p [20:12:43] <colomar> *gg* [20:13:57] <colomar> But we can do that better than proprietary software ever can, because we all work together :) [20:15:44] <colomar> I think we have some pretty good ideas about where we're going now. I guess we can start moving backwards from that to define what needs to be done [20:17:19] <colomar> I assume that both UI design and technical design need to be done next [20:17:46] <colomar> (okay, that wasn't exactly moving backward from the goal but... whatever) [20:18:50] <colomar> On the UI design side what we need is [20:19:00] <colomar> a) A UI for initiating tasks [20:19:04] <notmart> some example: http://www.automator.us/leopard/index.html [20:19:04] <aseigo> bwuahaha.i was just about to paste http://www.macosxautomation.com/automator/index.html [20:19:04] <aseigo> i don't think we need anything nearly that complex [20:19:04] <notmart> applications could provided a minimal standardize dbus interface for task control [20:19:04] <aseigo> but, yes ... [20:19:04] <notmart> like a task status, start (task name", param1, param2, ..) [20:19:05] <notmart> status, busy, ready [20:19:05] <notmart> finished() signal [20:19:05] <aseigo> notmart: which we need for slc [20:19:05] <aseigo> implementation detail: it will be possible for people to start more than one of these things at the same time (or on different activities) [20:19:05] <aseigo> which means we need a way to store the workflow steps while it is being done with an id that can be addressed by the application(s) involved [20:19:05] <notmart> aseigo: hmm, and that interface where would be? on the application or on slc, ie all in the activity manager daemon? [20:19:05] <aseigo> notmart: i think the daemon should store the active workflows and orchestrate them [20:19:05] * notmart hopes we won't walk out of the meeting sayng " i know what's needed: a new programming language!!" :p [20:19:05] <Shaan7> lol [20:19:05] <rubentje1991> :-D [20:19:05] <aseigo> ok, designing out loud here: the applications that support Workflows would get a workflow object that connects to the daemon [20:19:06] <aseigo> the application can set the status of its job, and when it is complete, then the next bit of the workflow starts [20:19:06] <aseigo> all connecting, sharing, etc. tasks could be routed through SLC itself so that we neither duplicate functionality or have things you can do in workflows you can't in SLC, and vice versa [20:19:06] <aseigo> so SLC handles S, L, C tasks [20:19:06] * Shaan7 has to go early, sadly, 1AM here :/ [20:19:06] <aseigo> applications handle content creation [20:19:06] <aseigo> Shaan7: thanks for coming! [20:19:06] <notmart> Shaan7: gnight ;) [20:19:06] <aseigo> kamd handles keeping state and stepping through the workflow [20:19:06] <Shaan7> gnite guys :) [20:19:06] <aseigo> notmart: does that sound potentially sane? [20:19:11] <colomar> b) A UI for creating tasks [20:19:21] <aseigo> if we insist that a workflow can only ever have one application active in it at a time, this becomes very simple [20:19:26] <notmart> aseigo: hmm, maybe still not getting the details [20:19:36] <aseigo> colomar: haha.. sorry, we just started running away on you to implementation ;) [20:19:43] <notmart> how you tell slc "start orchestrate this sequence of tasks"? [20:20:06] <aseigo> notmart: think of the workflow as a chain of applications or SLC actions to be done one after the other [20:20:29] <aseigo> notmart: the workflow creation UI would assemble the workflow and send it to kamd [20:20:49] <aseigo> notmart: kamd would then use that description as a state machine to step through .. "ok, launch this app to do that" [20:21:13] <colomar> Shaan7: gnite. Hope you'll be able to join the next meeting as well [20:21:18] <aseigo> if an app supports workflows natively, it could connect with kamd to let it know its progress; otherwise kamd could watch PIDs [20:21:42] <colomar> aseigo: No problem. for some reason Konversation stopped displying new messages and then spewed them out all at once [20:21:48] <rubentje1991> would going backwards in workflow be possible [20:21:59] <rubentje1991> ? [20:22:06] <colomar> I was already thinking everyone had suddenly fallen asleep or loist consciousness [20:22:09] <aseigo> rubentje1991: hopefully not in the first version [20:22:11] <aseigo> colomar: lol [20:22:14] * aseigo faints [20:22:18] <rubentje1991> :-P [20:22:36] Quit ksinny has left this server (Remote host closed the connection). [20:22:37] <aseigo> rubentje1991: that's a significantly tricky thing to do because you need to keep versions of the data at each point and know which steps are not time reversable [20:22:49] <rubentje1991> yep, i know it's not easy [20:22:51] <aseigo> let's get "going forwards in time" working at least :) [20:22:54] <rubentje1991> just keeping in mind: user = errors [20:23:00] <rubentje1991> yes, for sure [20:23:08] <aseigo> being able to modify a workflow in progress ... [20:23:13] <aseigo> or add to it ... [20:23:41] <colomar> yes. I agree with aseigo: Being able to go backwards is the idea, but it's for later versions [20:24:00] <rubentje1991> nice [20:24:07] <rubentje1991> to know it's thought of [20:24:17] <aseigo> colomar: do you think it would be useful to show what the current workflow is doing / will be doing? [20:24:23] <rubentje1991> step for step - we'll see what happen [20:24:32] Whois rubentje1991 is [email protected] (purple) [20:24:32] Whois rubentje1991 is a user on channels: #active [20:24:32] Whois rubentje1991 is online via moorcock.freenode.net (TX, USA). [20:24:32] Whois rubentje1991 has been idle for 10 seconds. [20:24:32] Whois rubentje1991 has been online since 16.01.2013 18:49:54. [20:24:32] Whois End of WHOIS list. [20:24:42] <aseigo> e.g. be able to check somewhere quickly to see that the workflow was "make an image, save to device, send to facebook" and currently it is at "save to device"? [20:24:51] <rubentje1991> hmm [20:25:00] <colomar> Yes, I think that would be useful [20:25:02] <aseigo> (possibly even able to request to add to it?) [20:25:19] <colomar> We'd just need a good place to show that. Maybe in the peek? [20:25:20] <aseigo> if so .. do you think extending SLC with another Workflow icon would make sense, shown only when "in" a workflow [20:25:34] <aseigo> then it would always be available without having to do anything to applications [20:25:40] <colomar> ...or there, yes [20:25:42] <aseigo> peek is another place it could be [20:25:52] <aseigo> ok, so somewhere show something about "what the workflow you're in is" [20:25:55] <rubentje1991> peek from bottom [20:25:55] <colomar> Yes, definitely somewhere global [20:25:59] <aseigo> that will need some UI thoughts then [20:26:23] * aseigo just a small wet dream ... [20:26:50] <aseigo> god.. i switch activities and check the workflow button to remember what the hell it was i was doing again before i got interupted by that meeting about workflows? ;) [20:27:01] <rubentje1991> or multi touch gesture from some side [20:27:23] <notmart> aseigo: wouldn't be more a features for jobs/notifications ui? [20:27:24] * aseigo will not have to remember anything ever again! [20:27:35] <aseigo> notmart: yes, it could also go there [20:27:42] <kallecarl> where'd I put my tablet? [20:27:47] <aseigo> kallecarl: shit. [20:27:52] <rubentje1991> lost my remember-function in my head [20:27:59] <aseigo> kallecarl: this is why the real world needs ctrl-f ;) [20:28:23] <rubentje1991> "plasma glasses" [20:28:43] <colomar> kallecarl: Reminds me of the "Brain annex" you mentioned in the last meeting [20:28:53] <rubentje1991> instead of Google glasses [20:29:01] <rubentje1991> much more interesting [20:29:17] <kallecarl> not my idea ... As we may think (pdf somewhere); Vannevar Bush 1945 [20:29:22] Quit felix_ has left this server (Quit: ChatZilla 0.9.89 [Firefox 18.0/20130110193351]). [20:29:24] * notmart notes that the dream would become even wetter when one will be able to transfer workflows between devices [20:29:37] <aseigo> notmart: oh yeah [20:29:42] <kallecarl> could even do it with touch [20:29:59] <aseigo> colomar: i'm really in love with this idea now ... and so much to think about in terms of UI and implementation details ... do you think you have enough to start on UI mockups? [20:31:06] <kallecarl> we could start with one example implementation...it still seems like (at some level) there is a limited number of things that people do [20:31:14] <colomar> aseigo: Yes, I guess so. [20:31:31] Join ivan|somewhere has joined this channel ([email protected]). [20:31:52] <kallecarl> those tasks plus the ability to create or modify them should handle most of this [20:32:17] <colomar> notmart: Yes, in an ideal world, you could seemlessly switch between devices [20:33:19] * kallecarl has to go...thanks colomar for pulling this together. Would be nice to get some input from your uni work. [20:33:46] <colomar> I guess this is material for a "defensive publication". We surely don't want somebody else to patent it [20:33:48] <kallecarl> or your colleagues who are working in this area [20:33:58] <notmart> colomar: +1 [20:34:44] <colomar> kallecarl: Yes, I'm starting to see a research project about this on the horizon... :) [20:35:08] Quit ivan|home has left this server (Ping timeout: 245 seconds). [20:37:37] <colomar> Okay. So now I will try to get Björn, some colleagues and anyone else who wants to help and draw up some mockups during the coming weeks. Can you do some more system design in the meantime or do you need the mockups for that? [20:39:11] <aseigo> activities, workflows, share/like/connect ... this is feeling like a more and more "complete wall" concept [20:39:37] <aseigo> colomar: no, we can start on system design as many of the infrastructure needs are evident independent from UI presentation [20:39:58] <colomar> great [20:40:06] * aseigo has to go now ... thanks for keeping this rolling colomar! and thanks to everyone else who came! [20:40:28] <colomar> Thank you as well! [20:40:37] <notmart> ok, awesome [20:40:41] <colomar> Okay, so when should we meet the next time? [20:41:05] <notmart> aseigo: is this in line with the other ideas about slc you mentioned? is still valid? [20:41:13] <colomar> Sometime early next month maybe? [20:41:52] <notmart> maybe, probably the discussion is to be brought for a while in the ml topugh [20:42:10] <notmart> colomar: could you do a quick recap of what we said in a ml thread ? [20:42:33] <notmart> on there you could also post first rough mockups when you have [20:43:50] <colomar> notmart: Yes, I can write a recap. Don't know when I'll find the time, though. I found that it usually takes me a few hours to do these, so it may take a few days until I find the time [20:44:20] <notmart> that's fine [20:44:59] <notmart> for now just a rough log dump is ok, then if you can summarize few points in next days, no hurry is fine [20:45:49] <colomar> Yes. I'll send the log dump today [20:46:04] <colomar> Olay. So, meeting officially closed [20:46:36] <colomar> Thanks to all of you who joined, i found this to be very productive! [20:46:53] <notmart> colomar: you would need a judge wooden hammer for that :p