fluid-work IRC Logs-2010-09-28

[09:08:25 CDT(-0500)] <justin_o> just noticed that someones altered one of our old irc logs (from 2010-03-01) with some spam... I'm going to revert it now, but wondering if this has happened before
[09:14:16 CDT(-0500)] <jamon> what was the spam justin_o? http://wiki.fluidproject.org/pages/diffpages.action?pageId=13402660&amp;originalId=16777220 just shows changes to markup, doesn't look like content changed at all
[09:14:54 CDT(-0500)] <justin_o> jamon: I reverted it already...
[09:15:48 CDT(-0500)] <jamon> oh i was looking at the earlier version of the page justin_o
[09:16:06 CDT(-0500)] <justin_o> jamon: do a search for the word "gotcha" and you can see that a link was added next to it
[09:16:13 CDT(-0500)] <justin_o> oh okay
[09:42:37 CDT(-0500)] <jameswy> anastasiac, justin_o: Should we talk about tasking out the framework demo today?
[09:42:52 CDT(-0500)] <anastasiac> yes, please, jameswy
[09:43:32 CDT(-0500)] <anastasiac> justin_o is at home today, but we could do this on Skype, or here in IRC...
[09:44:10 CDT(-0500)] <jameswy> anastasiac, justin_o: Want to aim for Skype after lunch? Say, 1:30?
[09:44:36 CDT(-0500)] <anastasiac> I have a lunch date today - I can't guarantee when I'll be back, but I suspect closer to 2pm
[09:44:58 CDT(-0500)] <anastasiac> justin_o, when do you expect to be available this afternoon?
[09:45:34 CDT(-0500)] <jhung> jameswy: I've updated the Inline Edit wireframe. Want to take a look? http://source.fluidproject.org/svn/design/infusion/infusion-demo-redesign/Inline-Edit-03.png
[09:46:54 CDT(-0500)] <anastasiac> jhung, I'm guessing your 'hover' styles are also applicable for keyboard focus, right?
[09:47:25 CDT(-0500)] <jhung> of course.
[09:48:19 CDT(-0500)] <anastasiac> jhung, I know I haven't been in on the discussions for all this, but I have a question about the "save edits" icon - consider it 'user feedback'
[09:48:32 CDT(-0500)] <jhung> Sure!
[09:48:33 CDT(-0500)] <jameswy> jhung: Will take a peek in a minute!
[09:48:34 CDT(-0500)] <justin_o> anastasiac, jameswy: i should be around till 3:30
[09:48:35 CDT(-0500)] <anastasiac> to my mind, the presence of the icon implies that you must activate it in order to save your edits
[09:48:55 CDT(-0500)] <anastasiac> but that's not actually true, all you have to do is move focus away from the field
[09:48:59 CDT(-0500)] <jhung> anastasiac: yes.
[09:49:29 CDT(-0500)] <jhung> anastasiac: Done intentionally to help those users who are not accustomed to an inline edit style of interaction.
[09:49:48 CDT(-0500)] <anastasiac> justin_o, jameswy: would you be ok to meet at around 2pm-ish, whenever I get back from my lunch? i.e. are you ok with leaving it a bit flexible?
[09:50:04 CDT(-0500)] <anastasiac> jhung: hm... it seems a bit misleading...
[09:50:05 CDT(-0500)] <jhung> anastasiac: part of the problem is there's no indication how to save if someone is completely new and has begun editing.
[09:50:23 CDT(-0500)] <jhung> *if there is no icon or any other indicator.
[09:50:45 CDT(-0500)] <jhung> anatasiac: have any suggestions?
[09:50:46 CDT(-0500)] <justin_o> anastasiac: i'm fine with that
[09:51:48 CDT(-0500)] <anastasiac> jhung, I'm guessing that tabbing to the icon will actually cause the edit to save, even though the newbie will assume that they have to hit enter after they've tabbed to it - as a result, they might assume that before they've hit enter, their edit is not yet saved, and hence they could tab away to cancel their change - which isn't true...
[09:51:50 CDT(-0500)] <anastasiac> suggestions...
[09:51:55 CDT(-0500)] <anastasiac> hm...
[09:52:06 CDT(-0500)] <jameswy> anastasiac, justin_o: I have a 2:30 that'll likely go to 3 or 3:30, but I'm good otherwise.
[09:52:07 CDT(-0500)] <anastasiac> sorry, I don't mean to be a complainer without offering an alternative...
[09:52:20 CDT(-0500)] * anastasiac is thinking
[09:52:25 CDT(-0500)] * anastasiac realizes it's a tricky thing
[09:52:37 CDT(-0500)] <jhung> anastasiac: Don't think you're complaining at all. Yes, it is tricky.
[09:53:02 CDT(-0500)] <justin_o> jhung: one other thing about the wireframes is that I don't notice a "redo" icon... which if there may look similar to the save one...
[09:53:21 CDT(-0500)] <jhung> anatasiac: also, Enter does not necessarily Save. In multiple line fields, it does a CR/LR. So defocus / icon click is the sure way to save.
[09:54:17 CDT(-0500)] <jhung> justin_o: lol. I knew I forgot something. That would be a pain for the user wouldn't it?
[09:55:28 CDT(-0500)] <justin_o> jhung: yep, could be... jameswy gave mike and I a sample icon that just looks like a diskette... something like that might help
[09:56:02 CDT(-0500)] <anastasiac> jhung, yes: I meant 'enter' after focus has moved to the "save" icon. That's the normal expectation for a save button: tab to it, then hit enter to activate it
[09:56:48 CDT(-0500)] <jhung> antasiac: ah. Yes. It's misleading because it's not the activation of the icon that does the saving.
[09:56:54 CDT(-0500)] <anastasiac> right
[09:56:59 CDT(-0500)] * jhung hmmm
[09:57:05 CDT(-0500)] <justin_o> anastasiac, jhung: take a look at the inline edit demo http://build.fluidproject.org/infusion/demos/inlineEdit/simple/html/inlineEdit.html
[09:57:15 CDT(-0500)] <anastasiac> so the user might assume that they could 'cancel' the edit by not activating the save button
[09:57:24 CDT(-0500)] <jhung> justin_o: I did have a disk icon originally, but felt it a bit heavy for the interaction.
[09:57:34 CDT(-0500)] <justin_o> mlam and I have been starting to get functionality like this into the component... still have a bunch of work to do though
[09:57:54 CDT(-0500)] <justin_o> jhung: ah okay...
[09:58:40 CDT(-0500)] <justin_o> anastasiac: funny you should mention that... i was just chatting with colin and jameswy about that issue yesterday
[09:59:31 CDT(-0500)] <jhung> justin_o, anastasiac: tabbing off the current build of the inline edit doesn't save. It keeps it in a non-edit state, but not a saved state either.
[10:00:25 CDT(-0500)] <anastasiac> jhung: really??? that is... odd...
[10:00:38 CDT(-0500)] <anastasiac> is this what's happening in the demo justin_o just posted?
[10:00:44 CDT(-0500)] <jhung> yep
[10:01:01 CDT(-0500)] <anastasiac> so visually it looks to the user as though their change is there, but it's not?
[10:01:19 CDT(-0500)] <anastasiac> when was this change introduced??
[10:01:48 CDT(-0500)] <jhung> anatasiac: not sure how it's being stored. The change is visible, but the styling and Undo Edit text does not appear when tab defocused.
[10:01:52 CDT(-0500)] <justin_o> anastasiac: this is something that came in yesterday... still a lot of rough edges, but its a start for people to try out
[10:02:01 CDT(-0500)] <jameswy> jhung, justin_o, anastasiac: such wonderful chatter about inline edit! It is a tricky problem, because the conventions around it haven't really been established yet.
[10:02:02 CDT(-0500)] <jameswy> re: saving - the interaction is novel enough that, as jhung mentioned, the user might not know how to save or exit edit mode without some indicator. Enter, save button.
[10:02:02 CDT(-0500)] <jameswy> re: cancel - the evil designer within me wants to suggest that we do away with cancel entirely
[10:02:02 CDT(-0500)] <jameswy> re: save button - jhung, why a disk icon "heavy"?
[10:02:40 CDT(-0500)] <anastasiac> hm...
[10:03:24 CDT(-0500)] <anastasiac> so justin_o, this is a work in progress, right? It seems to me that if the change isn't actually saved, some affordance to allow the user to save must absolutely be presented - otherwise, they have no idea!
[10:04:00 CDT(-0500)] <justin_o> anastasiac: yep, that is the case... it remains in edit mode if it isn't saved...
[10:04:17 CDT(-0500)] <justin_o> so you have to save or cancel to leave edit mode
[10:04:19 CDT(-0500)] <jhung> jameswy: re: Cancel, yes... I don't think Cancel is needed.
[10:05:12 CDT(-0500)] <jameswy> jhung: You're thinking that undo is sufficient?
[10:05:27 CDT(-0500)] <jameswy> jhung: I sort of kinda maybe agree.
[10:05:48 CDT(-0500)] <jameswy> jhung: But I still think it's evil not to provide a cancel feature.
[10:06:14 CDT(-0500)] <anastasiac> justin_o, ok - I'll reserve judgement until the rest of the implementation is in place
[10:06:19 CDT(-0500)] <jhung> jameswy: re: disk icon - hard to explain, but it has too much physical presence and the metaphor is physical. Inline edit is short and quick... disk just doesn't feel in harmony with that. (drinking the zen tea this morning .
[10:06:51 CDT(-0500)] <jhung> jameswy: not necessarily evil for a simple quick edit which is what this component is intended for.
[10:06:59 CDT(-0500)] <justin_o> anastasiac: thanks... if you get a chance to play around with it, please do... cause that will help us know what needs changing or not
[10:07:10 CDT(-0500)] <jhung> jameswy: perhaps pseudo-wicked...
[10:07:34 CDT(-0500)] <justin_o> anastasiac: I think we still need some feedback before we can really know how to finish the implementation properly.
[10:07:46 CDT(-0500)] <anastasiac> justin_o: well, so far: presenting some kind of save icon seems required, that's my only feedback so far
[10:08:38 CDT(-0500)] <jameswy> jhung: And yet, the conventional save icon is a disk. It's a broken metaphor now that we don't use disks anymore, but it's still the most familiar to most users. I feel bad about breaking that.
[10:08:54 CDT(-0500)] <justin_o> anastasiac: okay.. i think jameswy and jhung may be contemplating changing the defaults to have visible buttons for inline edit, but I could be mistaken
[10:10:11 CDT(-0500)] <jhung> jameswy: I just have a secret agenda to kill the floppy. I'll take a look at the disc icon. The way it gets rendered on screen may help.
[10:10:22 CDT(-0500)] <jhung> jameswy: send me a link to it?
[10:11:03 CDT(-0500)] <jhung> justin_o: I'm thinking at least some sort of control to Save an edit, whether it's an icon, or a text link.
[10:11:51 CDT(-0500)] <jameswy> jhung: re: cancel - I'm pretty sure we need to provide cancel functionality. Think about the user who accidentally clicks on one of these innocuous inline edits, and thinks, "Crap, what did I just do? How do I get out of this?" – save is not the option for him/her-he/she does not want to save-he/she wants to get out. It was a mistake, a mistake, I tell you!
[10:12:09 CDT(-0500)] <anastasiac> jhung, jameswy, justin_o, this change (from auto-save to not auto-save) seems like a rather radical change in functionality for a point-release of a production-level component. michelled and I were discussing these kinds of things yesterday
[10:12:38 CDT(-0500)] <jhung> justin_o: jameswy and I were talking yesterday and we both feel that inline edit should give more functionality by default since the interaction is novel. Then the integrator can choose to remove functionality (like save links/icons, edit field indicator etc.) if they want. Depends on their context.
[10:12:51 CDT(-0500)] <colinclark> mlam, justin_o: I think I just caught something in the Inline Edit demo...
[10:13:14 CDT(-0500)] <colinclark> It looks like the Edit/Save text button isn't preventing the default action on the anchor
[10:13:32 CDT(-0500)] <colinclark> Thus we are loading the #_ anchor
[10:13:35 CDT(-0500)] <colinclark> i.e. the URL ends up as http://build.fluidproject.org/infusion/demos/inlineEdit/simple/html/inlineEdit.html#_
[10:13:40 CDT(-0500)] <justin_o> anastasiac, jhung: this is a good question about what we need to preserve to maintain our backwards compatibility
[10:13:42 CDT(-0500)] <jameswy> anastasiac, jhung, justin_o: I think I might've missed something. We're removing auto-save?
[10:14:11 CDT(-0500)] <jhung> jameswy: sure, I don't think there's any harm to have Cancel as long as there's flexibility in it's visibility and appearance.
[10:14:21 CDT(-0500)] <anastasiac> I might be misunderstanding, but that's what I understood from what jhung said at 10:59
[10:15:17 CDT(-0500)] <justin_o> colinclark: ooops... thanks for spotting that... mlam posted a patch this morning that should address the missing dependencies and add comments to the IoC parts in the code
[10:15:24 CDT(-0500)] <colinclark> cool
[10:15:34 CDT(-0500)] <colinclark> I'm just catching up on the IRC logs now
[10:15:43 CDT(-0500)] * colinclark hasn't seen the word "diskette" in years
[10:15:57 CDT(-0500)] <mlam> justin_o: will you be committing the patch today?
[10:16:06 CDT(-0500)] <justin_o> colinclark: when you have a moment we can we also continue on the conversation that my battery decided to end yesterday
[10:16:15 CDT(-0500)] <jhung> anastasiac: Yes, you got that right. The visual style when tabbing off an edited field looks different than the visual presentation of a field that was edited and defocused using a mouse.
[10:16:18 CDT(-0500)] <justin_o> mlam: just looking at it now
[10:17:02 CDT(-0500)] <colinclark> justin_o: Sure, just let me finish reading the logs
[10:17:14 CDT(-0500)] <anastasiac> jhung: why different, and does one of those scenarios save and the other not?
[10:17:21 CDT(-0500)] <justin_o> jhung, jameswy, anastasiac: well it's sort of in between at the moment... if you shift tab off it still does an auto-save... so this is buggy at the moment.
[10:17:31 CDT(-0500)] <justin_o> colinclark: thanks
[10:18:28 CDT(-0500)] <jhung> anastasiac: not sure if it's saving at all. All I know is that the tab defocus style is different than the mouse defocus. So if we're assuming the mouse defocus is a proper indicator that contents of a text field is saved, then I would assume that tab defocusing is not saving.
[10:18:40 CDT(-0500)] <anastasiac> hm
[10:18:42 CDT(-0500)] <jhung> anastasiac: I have no way of confirming this without seeing the code.
[10:19:47 CDT(-0500)] <jhung> * also, by tab defocus style, it also excludes an Undo link.
[10:20:11 CDT(-0500)] <jameswy> jhung, anastasiac, justin_o: I'm getting a sneaking suspicion that we're overloading inline edit with too many explicit affordances. The more we try to make things obvious, the more complicated things are becoming.
[10:20:41 CDT(-0500)] <anastasiac> the original design of inline edit was: if you leave the component, it saves, you don't have to do anything yourself
[10:20:51 CDT(-0500)] <anastasiac> I think if we do something that changes that, we'd better have a good reason
[10:21:11 CDT(-0500)] <jameswy> anastasiac: I agree.
[10:21:23 CDT(-0500)] <jhung> jameswy: yes. I agree. But please someone think of the newbies!
[10:21:51 CDT(-0500)] <jameswy> anastasiac: But there's also the question of where the bounds of the component are--is it just the text field, or is it the text field and its accompanying buttons?
[10:22:25 CDT(-0500)] <jhung> jameswy: this may be one of those interactions that they'll get immediately once they've experienced it once. I guess in that way, we should provide an easy way of undo, redo, and cancel?
[10:22:36 CDT(-0500)] <anastasiac> I'd say the component includes accompanying buttons, but there never used to be a save button - save happened automatically
[10:22:42 CDT(-0500)] <jhung> jameswy: just so they can experiment and feel safe.
[10:47:19 CDT(-0500)] <athena> hey anastasiac - you around this morning?
[10:57:52 CDT(-0500)] <anastasiac> athena: I'm here now, but about to head out... what's up?
[10:58:18 CDT(-0500)] <athena> it sounds like there's some interest here at the unicon office in maybe meeting with you guys about documentation if you have time this week
[10:58:41 CDT(-0500)] <athena> so just wanted to touch base w/ you - want me to send you an email?
[10:58:55 CDT(-0500)] <anastasiac> that would be great! yes, please - send an email, and we can work out times, etc
[11:00:44 CDT(-0500)] <athena> sounds great cya!
[11:17:33 CDT(-0500)] <colinclark> mlam, you know, it might be clearer to actually take a tour through the Uploader before I started chopping away at it
[11:17:42 CDT(-0500)] <colinclark> You'll have a better sense of the transition from here to there
[11:17:51 CDT(-0500)] <colinclark> Where "there" is not quite fully realized
[11:18:00 CDT(-0500)] <mlam> ok, i'll do that then
[11:18:06 CDT(-0500)] <colinclark> And I have not-quite-working uncommitted code that is structurally substantial sitting in my working copy
[11:18:13 CDT(-0500)] <colinclark> So look at the trunk implementation
[11:18:16 CDT(-0500)] <mlam> ok
[11:18:29 CDT(-0500)] <colinclark> Take a bit of time to get to know the relationship between objects, however awkward they may be
[11:18:33 CDT(-0500)] <colinclark> So you'll find a few things...
[11:19:04 CDT(-0500)] <colinclark> Uploader serves as a sort of "central hub" for coordinating events, as well as handling the View for general, Uploader-wide things such as the total progress bar, and the various buttons.
[11:19:33 CDT(-0500)] <colinclark> FileQueueView is a stand alone component that responds to various events by actually modifying the DOM to draw the file queue, manage each individual file's progress bar, and the like.
[11:19:40 CDT(-0500)] <colinclark> Then things start to get a bit fuzzier, architecturally
[11:20:02 CDT(-0500)] <colinclark> There is the concept of an "upload manager," which was originally a purely Model-based construct
[11:20:12 CDT(-0500)] <mlam> ok, thanks
[11:20:25 CDT(-0500)] <colinclark> It wrapped SWFUpload's many, many quirks (and bad API designs) and tried to shield our users from having to be concerned with it
[11:20:56 CDT(-0500)] <colinclark> You'll find that there's then also a DemoUploadManager, which stubs out a bit of SWFUpload's behaviour to allow it to be used and tested with even when there's no server present.
[11:21:47 CDT(-0500)] <colinclark> Then, lastly, you'll find a very perplexing thing called the SWFUploadSetupDecorator, which was slapped on in a rush when Adobe "improved" Flash by preventing users from enabling the file browse dialog without having clicked on a real Flash Button
[11:21:53 CDT(-0500)] <colinclark> Previously the Uploader had been all HTML
[11:22:09 CDT(-0500)] <colinclark> But now we actually have to embed a real Flash button in the mix, which is the source of all our accessibility problems
[11:22:26 CDT(-0500)] <mlam> hokily dokily sounds like i have a ton to go through
[11:22:29 CDT(-0500)] <colinclark> So that setup decorator is responsible for doing all the quirky things to get SWFUpload to work correctly with Flash 10
[11:22:51 CDT(-0500)] <colinclark> You'll also find some really dreadfully factored objects, the fileQueue and then the fileQueueManager
[11:23:04 CDT(-0500)] <colinclark> You'd be right to be puzzled by the question "what's the difference?"
[11:23:15 CDT(-0500)] <colinclark> The fileQueueManager was a temporary thing that stuck around
[11:23:23 CDT(-0500)] <colinclark> In my branch I've merged the fileQueue and Manager together
[11:23:38 CDT(-0500)] <colinclark> Trashed the setup decorator
[11:23:59 CDT(-0500)] <colinclark> And moved all the generic, non-SWFUpload-specific behaviour of the UploadManager into the Uploader itself.
[11:24:08 CDT(-0500)] <colinclark> So less objects, and a much cleaner separation of concerns
[11:24:26 CDT(-0500)] <colinclark> This will let us swap out the whole SWFUpload subsystem in favour of an HTML 5 implementation
[11:24:40 CDT(-0500)] <colinclark> And it strikes me that it's easier to do this refactoring now, rather than once we start actually building the HTML 5 version
[11:25:03 CDT(-0500)] <colinclark> mlam: So there's a lot
[11:25:12 CDT(-0500)] <mlam> haha yah
[11:25:21 CDT(-0500)] <colinclark> There may be an old architectural diagram in the wiki that illustrates the various pieces. Let me take a quick look
[11:25:42 CDT(-0500)] <colinclark> Rest assured that I'll toss these meetings and we'll get a chance to actually code on this--if not this afternoon, then definitely tomorrow.
[11:25:52 CDT(-0500)] <mlam> ok
[11:25:56 CDT(-0500)] <mlam> sounds good to em
[11:25:56 CDT(-0500)] <mlam> em
[11:25:57 CDT(-0500)] <mlam> me
[11:25:59 CDT(-0500)] <mlam> ugh.
[11:26:50 CDT(-0500)] <colinclark> This is pretty dated: http://wiki.fluidproject.org/display/fluid/Architecture+Sketches#ArchitectureSketches-UploaderArchitecture
[11:26:54 CDT(-0500)] <colinclark> But it might help a tiny bit
[11:49:45 CDT(-0500)] <colinclark_> justin_o: So we were chatting via IM, but here seemed better
[11:49:47 CDT(-0500)] <colinclark_> sorry about that
[11:50:05 CDT(-0500)] <colinclark_> So, playing around with the new Inline Edit, I see what is a deeper issue than what I had understood before
[11:50:14 CDT(-0500)] <colinclark_> So, we have a clear bug that should be quite fixable:
[11:50:43 CDT(-0500)] <colinclark_> When we navigate via keyboard out of the Inline Edit container, we should return to view mode, saving the users changes automatically.
[11:51:03 CDT(-0500)] <colinclark_> That part, you mentioned, is a bug to do with our use of deadMansBlur(), perhaps?
[11:51:18 CDT(-0500)] <colinclark_> But the second issue is a little deeper, and more difficult to solve
[11:51:51 CDT(-0500)] <colinclark_> So when the Edit/Save button is hidden, it's not in the tab order in view mode, which is cool
[11:51:57 CDT(-0500)] <colinclark_> But in edit mode, it's there, even if it's hidden
[11:52:07 CDT(-0500)] <colinclark_> Fine for a screen reader user, since they'll have a manual control to work with
[11:52:07 CDT(-0500)] <colinclark_> B
[11:52:21 CDT(-0500)] <colinclark_> But for a sighted user who is using the keyboard, there is an extra, invisible tab stop
[11:52:40 CDT(-0500)] <colinclark_> They have to hit Tab twice to get out of the container, but there's no visual indication of what is there or why
[11:52:55 CDT(-0500)] <colinclark_> not to mention that if they hit return on this Invisible Entity, they actually save their changes as well
[11:53:04 CDT(-0500)] <colinclark_> This is an interesting one
[11:53:10 CDT(-0500)] <colinclark_> justin_o: Does this all sound about right?
[11:53:16 CDT(-0500)] <justin_o> colinclark_: yep
[11:53:43 CDT(-0500)] <colinclark_> I guess, if nothing else, the save button absolutely always need to be visible if it is included in the Tab order
[11:54:01 CDT(-0500)] <colinclark_> Even if the edit button isn't visible
[11:54:24 CDT(-0500)] <justin_o> colinclark_: so what should happen when a user tabs to the save button and tabs away from it
[11:54:27 CDT(-0500)] <justin_o> should it save?
[11:54:35 CDT(-0500)] <colinclark_> That's another question
[11:54:42 CDT(-0500)] <colinclark_> I don't have an immediate answer to it
[11:54:54 CDT(-0500)] <colinclark_> Superficially, I'd say it should save regardless
[11:55:10 CDT(-0500)] <colinclark_> But then we add this extra control, only for a user to find that it doesn't actually exclusively control the interaction
[11:55:17 CDT(-0500)] <colinclark_> Meaning, the save button saves, but so does anything else
[11:55:27 CDT(-0500)] <colinclark_> which was anastasiac's point from this morning
[11:58:54 CDT(-0500)] <justin_o> colinclark_: yep... the richtext inline edit works like this... it has explicit save and cancel buttons and those are the way you leave edit mode
[12:01:20 CDT(-0500)] <colinclark_> yes
[12:01:44 CDT(-0500)] <colinclark_> But simple Inline Edit, as James has mentioned, is really optimized for "quickly edit, then get out"
[12:01:51 CDT(-0500)] <colinclark_> So we're putting some rough edges on that style
[12:02:04 CDT(-0500)] <colinclark_> But then you have to balance that with the discoverability issue, too
[12:02:11 CDT(-0500)] <colinclark_> Will users know that these things are editable, and saveable
[12:02:15 CDT(-0500)] <colinclark_> Not clear
[12:02:31 CDT(-0500)] <colinclark_> But, really, an a11y fix has just pushed on a series of usability questions
[12:02:42 CDT(-0500)] <colinclark_> All good, but perhaps we're not quite out in the clear with Inline Edit yet
[12:03:11 CDT(-0500)] <colinclark_> With all of our talk about visibility of new code yesterday, I think today's conversations and more testing proves just how important it is to get features into the light early
[12:03:17 CDT(-0500)] <colinclark_> So that's really good
[12:07:04 CDT(-0500)] <justin_o> colinclark_: that's true, I think this has really been pushed into the light. If this had stayed hidden till closer to the release we may have either put it in with a bunch of problems unknowingly or would have had to pull it if we didn't have time to fix the issues
[12:19:41 CDT(-0500)] <mlam> colinclark_: justin_o : do we still want to show this new feature in the upcoming demo with so many surrounding uncertainties?
[12:21:43 CDT(-0500)] <justin_o> mlam: good question... i guess it depends on what Jan wants to show... if Jan is going to go up there and say Fluid is working on some improvements to inlineEdit and here is a start, then it might be okay... but if wants to show something more concrete I'm not sure it will be ready in time and we would probably want to pull it back
[12:21:53 CDT(-0500)] <justin_o> colinclark_: what do you think?
[12:24:09 CDT(-0500)] <jessm> justin_o: i think colinclark_ is getting some grub
[12:24:18 CDT(-0500)] <justin_o> jessm: thanks
[12:24:40 CDT(-0500)] <jessm> justin_o: can we get an enumeration of the issues affecting inline edit? a break-down of all that's been discussed?
[12:24:45 CDT(-0500)] <jessm> or do we have that already?
[12:25:31 CDT(-0500)] <justin_o> jessm: did you want me to mention them here or send an e-mail off to the list?
[12:26:45 CDT(-0500)] <jessm> justin_o: you know how i love emails to the list
[12:27:32 CDT(-0500)] <justin_o> okay.. i'll write one up.
[12:55:59 CDT(-0500)] <colinclark_> back from lunch
[12:56:20 CDT(-0500)] <colinclark_> I think our goal, if we can do it, is to chip away at these issues this week in order to make for a good demo for the AEGIS conference.
[12:56:29 CDT(-0500)] <colinclark_> So we want to keep up the focus on Inline Edit
[12:57:43 CDT(-0500)] <anastasiac> jameswy, justin_o: I'm back from lunch, ready whenever you are to task the framework demo
[12:58:04 CDT(-0500)] <anastasiac> jameswy, I see that you're on a call; after that is fine with me
[13:05:11 CDT(-0500)] <mlam> colinclark_: would you prefer i keep focus on inline edit instead of the uploader?
[13:47:22 CDT(-0500)] <colinclark_> mlam: Let's have a super quick chat with justin_o when he's off with anastasiac about Inline Edit next steps
[13:47:36 CDT(-0500)] <mlam> ok
[13:54:28 CDT(-0500)] <justin_o> colinclark_, mlam: okay... all done
[13:54:47 CDT(-0500)] <mlam> ok
[13:55:09 CDT(-0500)] <justin_o> colinclark_, mlam : did you want to talk here or skype?
[13:55:20 CDT(-0500)] <colinclark_> i need about two more minutes
[13:56:08 CDT(-0500)] <justin_o> okay
[14:42:57 CDT(-0500)]

[14:47:14 CDT(-0500)] <Bosmon> So... I think we need to step back and present some core aspects of the IoC system...
[14:47:49 CDT(-0500)] <Bosmon> So.... The IoC system exposes what are essentially two distinct facilities.... one is what you could call VALUE RESOLUTION, and the other is FUNCTION RESOLUTION
[14:47:53 CDT(-0500)] * anastasiac is just realizing the silliness of her question
[14:48:22 CDT(-0500)] <Bosmon> These processes have many elements in common, and use many common ideas and functions, but they are essentially separate
[14:48:50 CDT(-0500)] <Bosmon> So, for a start, it is possible to apply VALUE RESOLUTION essentially anywhere, entirely unrelated to any demands blocks or components or anything of that kind
[14:49:21 CDT(-0500)]

<Bosmon> In many ways this resolution really isn't very different to what we already had in Engage... you are able to write expressions of the form

Unknown macro: {context}

.pathName, and have them resolves

[14:49:24 CDT(-0500)] <Bosmon> resolved
[14:50:18 CDT(-0500)] <Bosmon> The only difference is the slight extension to what is permissible for a "context" - as well as the "static context", and the "threadlocal context", you can also resolve into the "thatStack context"
[14:51:01 CDT(-0500)] <Bosmon> So, in every case, the behaviour is the same, you ingest a whole bunch of JSON, and throw out a modified bunch of JSON with these context values resolved
[14:51:28 CDT(-0500)] <Bosmon> So, a particular subcase of this is the case where the bunch of JSON is "going to be" the options for a component configuration tree
[14:51:57 CDT(-0500)] <Bosmon> In this case, there are "some extra" possibilities for the allowed context names, in particular, you can refer to things in the "that stack" - that is, the tree of components that are currently instantiating
[14:52:16 CDT(-0500)] <Bosmon> Or rather, "will be", when the block of JSON you have written is in the process of being interpreted as component configuration
[14:52:36 CDT(-0500)] <Bosmon> So - essentially separate from that is the process of FUNCTION RESOLUTION
[14:53:02 CDT(-0500)] <Bosmon> Just like value resolution, this has essentially nothing in particular that ties it to the situation of subcomponents or supercomponents
[14:53:22 CDT(-0500)] <Bosmon> "Any function" can be the "demanding name" during function resolution, and "any function" can be the "resolved name"
[14:54:00 CDT(-0500)] <Bosmon> But, just as in the case for VALUE RESOLUTION, there are extra sources of "context" available to guide the resolution, when it can be determined that the "demanding name" has been used in the context of a particular component tree
[14:54:28 CDT(-0500)] <Bosmon> In particular, all the names of types and nicknames for components so far seen in the tree are added to the set of "context names" which can be used to guide resolution
[14:55:11 CDT(-0500)] <Bosmon> So... the common elements between these two types of resolution is that they make use of CONTEXT NAMES which are derived by roughly the same rules in each situation (although there are still a few irregularities about this)
[14:55:21 CDT(-0500)] <Bosmon> But really there is "nothing in particular" that ties these two processes together
[14:55:53 CDT(-0500)] <Bosmon> In particular, the fact that you might or might not use a context name for value resolution that you just used for function resolution is just a matter of "coincidence"
[14:56:12 CDT(-0500)] <Bosmon> but clearly, in the cases like the one you asked about, it is a particularly "meaningful coincidence"
[14:57:08 CDT(-0500)] <Bosmon> For example, the fact that you just asked for FUNCTION RESOLUTION using a context name which was the context name of something that you KNOW to be a supercomponent type name, means that it is pretty likely that you could and might very often find desirable to use that same context name for VALUE RESOLUTION for the arguments of this function
[14:57:28 CDT(-0500)] <Bosmon> So, to answer your question.... "yes"
[14:58:48 CDT(-0500)] <anastasiac> Bosmon, this is great information - very helpful, thanks!
[14:59:10 CDT(-0500)] <anastasiac> I have an unrelated question, around the word "demand", Bosmon:
[15:00:36 CDT(-0500)] <anastasiac> Does a 'supercomponent' "demand" a subcomponent (e.g. autocomplete demands a popup), or does a subcomponent demand things of a supercomponent (e.g. the popup demands the supercomponent's model)? or both?
[15:01:18 CDT(-0500)] <Bosmon> Well, neither, really....
[15:01:32 CDT(-0500)] <Bosmon> Well, the usage of "demand" so far I think had been primarily tied to FUNCTION RESOLUTION
[15:01:39 CDT(-0500)] <Bosmon> That is what demands blocks actually specifity
[15:01:42 CDT(-0500)] <Bosmon> specify
[15:02:08 CDT(-0500)] <Bosmon> but I guess the use of the word is a bit unclear
[15:02:29 CDT(-0500)] <anastasiac> yeah, I guess that's why I was asking but I do think your answer helps, a bit
[15:02:42 CDT(-0500)] <Bosmon> I guess we should think about what it might be meant to mean
[15:02:53 CDT(-0500)] <anastasiac> LOL
[15:03:05 CDT(-0500)] <Bosmon> Probably when the word was first used, the distinction between the two resolution processes wasn't terribly clear
[15:03:26 CDT(-0500)] <anastasiac> writing documentation requires picking appropriate teminology for things, so I want to make sure I'm not mis-understanding things, leading to mis-using terminology
[15:03:27 CDT(-0500)] <Bosmon> We call the function name which is the first argument to fluid.demands, the "demanding name" or perhaps the "demanded name"
[15:03:41 CDT(-0500)] <Bosmon> I guess the two versions of that have slightly different connotations
[15:03:54 CDT(-0500)] <anastasiac> yes, that's problematic - that's what confused me!
[15:04:34 CDT(-0500)] <Bosmon> So yes, it's unclear whether the use of "demand" is referring to the fact that the client is wanting something done by "demanding the name of a function" or whether the configuration resolution is "demanding values from the environment"
[15:04:55 CDT(-0500)] <anastasiac> so if we tried to re-name the parameter without using "demand" at all, what might we call it?
[15:05:03 CDT(-0500)] <anastasiac> just as an exercise...
[15:05:08 CDT(-0500)] <Bosmon> The name seems to work well in both contexts
[15:05:17 CDT(-0500)] <Bosmon> Perhaps, as sgithens_ might say, it is a bit "artistic"
[15:05:43 CDT(-0500)] <sgithens_> what?
[15:05:49 CDT(-0500)] <Bosmon> Well... I guess it could be called something like "inputName"... or "functionName".... or "clientName"
[15:05:56 CDT(-0500)] <anastasiac> so which would be more appropriate for the first parameter to fluid.demands(), demandingName, or demandedName?
[15:06:08 CDT(-0500)] <Bosmon> It's hard to say in that case
[15:06:15 CDT(-0500)] <Bosmon> Both of them seem possibilities
[15:06:24 CDT(-0500)] <sgithens_> ugh, it's like trying link tickets in jira
[15:06:29 CDT(-0500)] <anastasiac> LOL
[15:06:41 CDT(-0500)] * anastasiac never gets that right
[15:06:43 CDT(-0500)] <Bosmon> It is either "the client's name for the function which was demanded"
[15:06:58 CDT(-0500)] <Bosmon> Or "the function which is a key to a block which will demand environmental values"
[15:07:13 CDT(-0500)] <anastasiac> hm...
[15:07:36 CDT(-0500)] <Bosmon> I mean, perhaps its actually a liability that the term "demands" works in both of these senses here
[15:08:52 CDT(-0500)] <Bosmon> I would have chosen "demandingName" since it keeps the ambiguity as unresolved as it was when you wrote "fluid.demands"
[15:09:02 CDT(-0500)] <anastasiac> LOL
[15:09:11 CDT(-0500)] <anastasiac> now there's a solution
[15:09:27 CDT(-0500)] <Bosmon> Poets always try to keep ambiguity unresolved...
[15:10:00 CDT(-0500)] <Bosmon> I mean, as long as you understand what it means it doesn't perhaps matter that you can't trace an unambiguous connection to why it is named that way...
[15:10:15 CDT(-0500)] <Bosmon> "the function name demanded by the client"...
[15:10:27 CDT(-0500)] <Bosmon> Or rather, "that will be demanded"
[15:10:35 CDT(-0500)] <Bosmon> Or might be
[15:10:55 CDT(-0500)] <Bosmon> "the function name that we allow that the client might demand"
[15:11:00 CDT(-0500)] <anastasiac> so, this "name" would be the same as the "type" in the defaults components section, right?
[15:11:18 CDT(-0500)] <Bosmon> Well again, there is no necessary connection
[15:11:37 CDT(-0500)] <Bosmon> subcomponent names and types are just examples of particular kinds of "demanding names"
[15:12:02 CDT(-0500)] <Bosmon> But yes, a configured subcomponent type is an example of a kind of "demanding name"
[15:12:12 CDT(-0500)] <Bosmon> But on the other hand, it is also an example of a "context name"
[15:12:20 CDT(-0500)] <anastasiac> yes, but if I have a type of "foo.bar", then I'd have to use the same string as the demandingName to fluid.demands() to register demands for that subcomponent, right?
[15:12:20 CDT(-0500)] <Bosmon> This coincidence is what makes the system so powerful
[15:12:45 CDT(-0500)] <anastasiac> otherwise, how would the system find the demandspec?
[15:12:46 CDT(-0500)] <Bosmon> Well, you could also use the "nickName"
[15:13:02 CDT(-0500)] <Bosmon> Well actually you couldn't right now... but you should be able to
[15:13:12 CDT(-0500)] <anastasiac> which in my example would be "bar", right?
[15:13:15 CDT(-0500)] <Bosmon> This is an example of a slight mismatch currently between names as context names and names as demanding names
[15:13:44 CDT(-0500)] <Bosmon> Well no, it could be the actual name of the subcomponent within the component
[15:13:55 CDT(-0500)] <Bosmon> So that you could distinguish multiple subcomponents of the same type
[15:14:01 CDT(-0500)] <anastasiac> oh!
[15:14:06 CDT(-0500)] <Bosmon> Right now this doesn't work, but it really should
[15:14:33 CDT(-0500)] <Bosmon> And it is a key to resolving your first question, "what is the relationship between defaults blocks and demands blocks"
[15:14:35 CDT(-0500)] <anastasiac> so right now, you'd have to use the type
[15:15:03 CDT(-0500)] <Bosmon> What will happen SOON, is that essentially EVERY "defaults" configuration for a subcomponent will be immediately rewritten into an equivalent "demands" block
[15:15:13 CDT(-0500)] <Bosmon> Which will then fully resolve any ambiguity
[15:15:21 CDT(-0500)] <anastasiac> so demands is the recommended way, not defaults - is that right?
[15:15:35 CDT(-0500)] <Bosmon> Right now you can't really get much done without a combination of both
[15:15:49 CDT(-0500)] <Bosmon> Well, "demands" is the more GENERAL way, i think it's fair to say
[15:16:03 CDT(-0500)] <Bosmon> "defaults" is a way of packing a lot of related configuration into one place
[15:16:10 CDT(-0500)] <anastasiac> but if I'm writing examples, etc., I'd like to demonstrate things the way we'd prefer people do it
[15:16:16 CDT(-0500)] <Bosmon> Without having to write a whole heap of separate demands blocks which would be less readable
[15:16:30 CDT(-0500)] <Bosmon> Well, I think we'd prefer people to do what was appropriate
[15:17:19 CDT(-0500)] <Bosmon> It should be possible to define a tree of related subcomponents all in one place
[15:17:40 CDT(-0500)] <Bosmon> But then at the same time it should be possible to selectively override parts of those configurations in particular contexts
[15:18:02 CDT(-0500)] <Bosmon> Basically right now, you can only use fluid.defaults to specify VALUE RESOLUTION
[15:18:18 CDT(-0500)] <Bosmon> Whereas you can use fluid.demands to express both kinds
[15:18:32 CDT(-0500)] <Bosmon> fluid.defaults needs to be generalised a bit so it is as capable as the other
[15:18:48 CDT(-0500)] <Bosmon> So then you can freely move configuration from one form to the other as you need to
[15:18:52 CDT(-0500)] <anastasiac> really? are you sure it doesn't do value resolution yet?
[15:19:01 CDT(-0500)] <anastasiac> I was playing with your autocomplete example
[15:19:12 CDT(-0500)] <Bosmon> I said it only specifies value resolution
[15:19:23 CDT(-0500)] <anastasiac> sorry, I meant to type function resolution
[15:19:26 CDT(-0500)] <Bosmon> Both kinds specify value resolution
[15:19:32 CDT(-0500)] <Bosmon> Well, function resolution occurs
[15:19:37 CDT(-0500)] <Bosmon> But it is not specified in the defaults block
[15:19:52 CDT(-0500)] <anastasiac> yes, but I modified it so that it was specified inthe defaults block
[15:19:53 CDT(-0500)] <Bosmon> It occurs during resolution of the defaults block, as specified by demands blocks which can be found
[15:20:07 CDT(-0500)] <anastasiac> i.e. I removed the demands block
[15:20:24 CDT(-0500)] <Bosmon> Well, if no demands block is found, it just assumes that you are meaning to configure a "little component"
[15:20:25 CDT(-0500)] <anastasiac> and added "funcName: "cspace.URLDataSource"," etc to the defaults block
[15:20:32 CDT(-0500)] <Bosmon> Right, but that isn't "resolution"
[15:20:36 CDT(-0500)] <Bosmon> That is just specification
[15:20:51 CDT(-0500)] <Bosmon> As I was saying to Colin the other day, "this name does not enter competition"
[15:21:12 CDT(-0500)] <Bosmon> So, "funcName" as specified there, is only allowed to be used as the INPUT to resolution
[15:21:17 CDT(-0500)] <Bosmon> just like any function name you might right anywhere
[15:21:33 CDT(-0500)] <Bosmon> This definition doesn't specify a rule which allows you to the RESULTS of resolution
[15:22:05 CDT(-0500)] <Bosmon> A "demands" block specifies a possible RESULT to resolution, that is, a possible "output function name" or "resolved name" + resolved argument information
[15:22:35 CDT(-0500)] <Bosmon> Whereas writing "funcName" in "defaults" right now only specifies what it is that you demand
[15:22:46 CDT(-0500)] <Bosmon> Of course, in many cases, what you demand is what you actually get
[15:22:59 CDT(-0500)] <Bosmon> But you don't need any IoC for that, that is just how functions have worked since 1950
[15:25:47 CDT(-0500)] <anastasiac> ok, well, I'm not quite clear yet on how what you get might not be what you demanded. clearly I still have to think a bit more about function resolution
[15:28:24 CDT(-0500)] <Bosmon> Well, if a "demands" block is found to match your situation when you demand a name, you get what it specifies
[15:28:57 CDT(-0500)] <Bosmon> That is, a demand for "REALLY STRONG BEER" could in the right context be satisfied by resolving to "JUST WATER"
[15:30:25 CDT(-0500)] <Bosmon> fluid.demands("cspace.autocomplete.matchesDataSource", ["cspace.localData", "cspace.autocomplete"],
[15:30:25 CDT(-0500)]

<Bosmon>

Unknown macro: {funcName}

);

[15:30:42 CDT(-0500)] <anastasiac> so if I understand what you said at 4:20, that's a case of function specification. what would be an example of function resolution?
[15:30:45 CDT(-0500)] <Bosmon> or in this case, a demand by the user for "matchesDataSource" in the matching context will actually resolve to "testMatchesDataSource"
[15:31:08 CDT(-0500)] <Bosmon> So, in most cases "resolution" happens automatically whenever things are being instantiated by the framework automatically
[15:31:17 CDT(-0500)] <Bosmon> So, it happens automatically for subcomponents for example
[15:31:26 CDT(-0500)] <Bosmon> But you can see sometimes you actually need to explicitly request it
[15:31:42 CDT(-0500)] <Bosmon> For example, with the different between "deferredCall" expander and "deferredInvokeCall" expander
[15:31:58 CDT(-0500)] <Bosmon> The latter will perform resolution of the client's "demanded name" and the former will not
[15:32:26 CDT(-0500)] <anastasiac> ah...
[15:32:52 CDT(-0500)] <Bosmon> So, in the former case, it doesn't matter what the client "demands" they will still get exactly what they demanded
[15:33:13 CDT(-0500)] <Bosmon> Whereas in the latter case, the name and function call will become "input to resolution"
[15:33:20 CDT(-0500)] <anastasiac> clouds parting, light starting to shine through in patches
[15:33:36 CDT(-0500)] <Bosmon> The definitions which are registered in the system by demands blocks will then "compete" and the one best matching the context will be used to satisfy the demand
[15:35:09 CDT(-0500)] <Bosmon> Once the correct "resolution definition" is picked, there will AFTER THAT follow a phase of "VALUE RESOLUTION"
[15:35:39 CDT(-0500)] <Bosmon> Where any arguments that were specified in the "demands" block will be resolved against the environment that the demanding client is calling from
[15:40:31 CDT(-0500)] <anastasiac> Bosmon, thanks so much - this has been very helpful
[15:41:00 CDT(-0500)] <anastasiac> I imagine you might feel like you just keep having to explain the same things over and over again, but I really appreciate your patience
[15:41:01 CDT(-0500)] <Bosmon> So, to be clear, all of these things are kinds of the same thing... "someone writes a function specification", "someone demands a function", "someone writes that a subcomponent should have a particular type", "someone in the world wants something done"
[15:41:19 CDT(-0500)] <Bosmon> All of these are cases where someone expresses their need, in the "real world", that they want something done
[15:42:05 CDT(-0500)] <Bosmon> So, assuming that they are in a context where "resolution" is configured in, or they explicitly ask for "resolution", this "call for something to be done" is matched against all the entries written in "demands blocks"
[15:42:42 CDT(-0500)] <Bosmon> If one of them matches, their original "request for something done" (generally expressed in the terms of calling a function with particular arguments", is replaced by another one, a "resolved one"
[15:43:27 CDT(-0500)] <Bosmon> Then at this point, this "resolved definition" can be used to weave together a new set of arguments for the "resolved request" which may just use their original arguments, or pick from them, or weave them into other values taken from elsewhere in the environment
[15:43:48 CDT(-0500)] <Bosmon> Then, finally, THIS NEW THING IS DONE.... that is, the function is executed
[15:43:54 CDT(-0500)] <Bosmon> And its result is returned to the caller in the usual way
[15:44:22 CDT(-0500)] <Bosmon> And this sequence of things shows what we call "FUNCTION RESOLUTION", followed by what we call "VALUE RESOLUTION"
[15:44:40 CDT(-0500)] <Bosmon> But there are clearly many cases where value resolution can just be done on its own.... like we did in Engage
[15:45:15 CDT(-0500)] <Bosmon> So, it's clear this something like 4-stage pipeline could be unpacked into separate pieces... the framework allows you to perform each of them individually, wherever they make sense
[15:45:39 CDT(-0500)] <Bosmon> So for example, you might want the final DO IT NOW stage to happen immediately, or happen later.... or happen just once, or be able to happen many times
[15:45:46 CDT(-0500)] <Bosmon> So this latter distinction is captured by what we call "invokers"
[15:45:57 CDT(-0500)] <anastasiac> right
[15:46:06 CDT(-0500)] <Bosmon> "invokers" give you control over how many times, and when, resolution occurs, with respect to ACTUALLY DOING THE THING
[15:46:09 CDT(-0500)] <anastasiac> we talked about those yesterday
[15:46:13 CDT(-0500)] <Bosmon> Right
[15:46:58 CDT(-0500)] <Bosmon> Sometimes you just want resolution, and then the THING, to occur right away, and then after that to forget about it
[15:47:07 CDT(-0500)] <Bosmon> This is the typical case of configuring a subcomponent
[15:47:24 CDT(-0500)] <Bosmon> Once the subcomponent is constructed, for the rest of its lifecycle, you may be no longer interest in IoC
[15:47:26 CDT(-0500)] <Bosmon> interested
[15:47:45 CDT(-0500)] <Bosmon> On the other hand, you may want to keep "resolving" things, again and again
[15:47:59 CDT(-0500)] <Bosmon> Again, it might be worth looking into the Spring documentation for this kind of thing.... since a similar issue comes up there
[15:48:06 CDT(-0500)] <Bosmon> It is possible, for example, to simply inject a "bean"
[15:48:17 CDT(-0500)] <Bosmon> Which means that IoC happens once, and then after that you are just a normal object tree
[15:48:24 CDT(-0500)] <Bosmon> On the other hand, you can do what is called "method injection"
[15:48:38 CDT(-0500)] <Bosmon> Which means that one method of your "bean" is replaced by an IoC-driven resolution
[15:48:44 CDT(-0500)] <Bosmon> So, this latter case is more like an "invoker"
[15:48:59 CDT(-0500)] <Bosmon> The IoC machinery becomes a permanent part of your lifecycle
[15:50:14 CDT(-0500)] <Bosmon> Of course the Spring version of this has lots of special-casing and lots of crazy terminology... deriving from the fact that they don't live in a uniform world of objects and functions
[15:50:32 CDT(-0500)] <Bosmon> "factory beans", "methods", "constructor injection", etc.
[15:51:03 CDT(-0500)] <Bosmon> Since we decided early on that there is no distinction to us between "creator functions" and "constructors", this kind of thing is a lot clearer to talk about
[15:51:28 CDT(-0500)] <Bosmon> I guess we wouldn't like to go for the "less clear" version of this conversation
[15:51:47 CDT(-0500)] <anastasiac> no, let's aim for "more clear", shall we?
[15:51:59 CDT(-0500)] <Bosmon>
[15:52:17 CDT(-0500)] <anastasiac> this has been very clarifying, actually
[15:54:27 CDT(-0500)] <Bosmon> Like butter