fluid-work IRC Logs-2011-01-06

Owned by Fluid IRC Log Bot
Last updated: Jan 06, 2011Version comment
15 min read

[00:10:51 CST(-0600)] <dhastha> Need help on my final year project. I am newbie to Fluid simulation. Can anyone tell me where i could start before coding part?
[00:17:08 CST(-0600)] <dhastha> anybody there?
[08:43:29 CST(-0600)] <heidi_> anastasiac how does one delete a wiki page? ex http://wiki.fluidproject.org/display/fluid/FSS+Links+Panel
[08:43:54 CST(-0600)] <anastasiac> heidi_, first off: why do you want to delete the links panel?
[08:44:13 CST(-0600)] <heidi_> anastasiac oops my bad - i don't (big grin)
[08:44:34 CST(-0600)] <heidi_> at first glance it looked like a blank page.
[08:44:48 CST(-0600)] <anastasiac> for the record, iirc, to delete a page, edit it, and while editing you should see a link in the upper right corner to delete the page
[08:44:54 CST(-0600)] <anastasiac> I think
[08:45:01 CST(-0600)] <heidi_> okay, thanks
[08:46:29 CST(-0600)] <heidi_> anastasiac is there a way to see what pages include another page?
[08:46:54 CST(-0600)] <heidi_> ex there is an fss order of files page that gets included in one page, is there a way to see if it's included by others?
[08:47:09 CST(-0600)] <anastasiac> heidi_, not that I know of - that's one downside of includes
[08:47:16 CST(-0600)] <anastasiac> you can see if pages link to a page, but not include
[08:47:26 CST(-0600)] <heidi_> ah, bummer
[08:47:29 CST(-0600)] <anastasiac> yeah
[09:42:04 CST(-0600)] <mlam> jhung: did you finish the inline edit JIRA gardening?
[09:42:35 CST(-0600)] <jhung> No. Got about 1/2 way. I was planning on getting back to it later this afternoon. Do you have time to look at it?
[09:43:45 CST(-0600)] <mlam> i can go through the rest of them. i should be finished with the uploader JIRAs by around noon
[09:44:17 CST(-0600)] <jhung> okay. Let me know when you want to start and I'll give you the Jira # I stopped at (going in ascending order).
[09:44:58 CST(-0600)] <mlam> ok, thanks
[09:58:50 CST(-0600)] <colinclark> Hey mlam, maybe this afternoon-once you've had a chance to finish the Uploader JIRAs-we can make a list of things we'd like to fix for Uploader 1.3.1
[09:58:52 CST(-0600)] <colinclark> if you're up for it
[09:59:04 CST(-0600)] <mlam> Yah, for sure
[09:59:42 CST(-0600)] <colinclark> cool
[09:59:46 CST(-0600)] <mlam> I already have a mental list of what I think should be done for the 1.3.1 release
[09:59:50 CST(-0600)] <colinclark> (smile)
[10:00:01 CST(-0600)] <colinclark> So, mlam, you're the boss when it comes to Uploader this time around
[10:00:16 CST(-0600)] <mlam> ok (smile)
[10:00:20 CST(-0600)] <colinclark> When you're making that mental list, you can also think about any issues you want to parcel off and make me fix (wink)
[10:00:45 CST(-0600)] <mlam> sure!
[10:08:55 CST(-0600)] <heidi_> anastasiac is there a way to archive pages or something... http://wiki.fluidproject.org/display/fluid/Methods+and+Limitations+for+dynamically+changing+styles seems dated but possibly a useful note for future dev. is there some way/common practice for separating dev notes from how-to documentation
[10:11:03 CST(-0600)] <anastasiac> heidi_, good question. We don't have a particular space/method for archiving pages. We do have a Development page, you could "move" it to be a child of that page, and put a link to it on that page, with an explanation of it's datedness and what it might still be good for - and make sure nothing else links to it
[10:11:53 CST(-0600)] <heidi_> anastasiac that sounds good - thanks!
[10:15:21 CST(-0600)] <colinclark> anastasiac, heidi_: That sounds exactly right...
[10:15:31 CST(-0600)] <colinclark> I'm actually thinking there's a whole category of pages that are interesting but no longer relevent
[10:15:47 CST(-0600)] <colinclark> I wonder if we should think briefly about a way to nicely archive older material as "reference"
[10:16:00 CST(-0600)] <colinclark> What do you think?
[10:16:22 CST(-0600)] <anastasiac> colinclark, I agree, we probably should set up an archive section for pages like these
[10:17:08 CST(-0600)] <colinclark> How should we do it?
[10:17:17 CST(-0600)] <colinclark> Is there a category of pages that we're looking at?
[10:17:36 CST(-0600)] <colinclark> I can imagine that there's definitely a difference between interesting, research-y, but no-longer directly relevant pages
[10:17:39 CST(-0600)] <colinclark> and old documentation pages
[10:17:50 CST(-0600)] <heidi_> i like the 'reference' word
[10:18:06 CST(-0600)] <colinclark> The latter can be much more problematic, and should either be removed or very clearly separated off so they can't do any damage
[10:18:16 CST(-0600)] <heidi_> and old doc 'archived'
[10:18:39 CST(-0600)] <anastasiac> colinclark, I was about to say the same thing about old docs pages - ideally, we wouldn't have any
[10:18:58 CST(-0600)] <colinclark> (smile)
[10:19:15 CST(-0600)] <anastasiac> but I could see the usefulness of having a place to move them until we figure out how to deal with them
[10:20:07 CST(-0600)] <colinclark> I tend to lean towards just tossing stuff if we think they're irrelevant
[10:20:20 CST(-0600)] <colinclark> So, I noticed for example that jhung had edited some old lightbox tutorial from 0.3
[10:20:25 CST(-0600)] <colinclark> and it was fascinating to me to see them still around
[10:20:32 CST(-0600)] <colinclark> I can imagine that it's useful to have them for posterity
[10:20:34 CST(-0600)] <anastasiac> !!!
[10:20:43 CST(-0600)] <colinclark> but I guess if people searched for these things, they might get inaccurate hits
[10:21:19 CST(-0600)] <colinclark> This is why I like, at least in principle, your approach to separating documentation out into a space where we can handle versioning
[10:21:51 CST(-0600)] <anastasiac> yes, I think that's probably a good criteria for whether to archive a page or remove it: will stumbling upon it be likely to confuse or mis-direct someone? If so, we probably shouldn't keep it: update it or remove it
[10:22:23 CST(-0600)] <anastasiac> and yes, versioning docs would avoid this issue
[11:27:33 CST(-0600)] <jhung> anastasiac: what documentation task should I tackle next?
[12:47:40 CST(-0600)] <heidi_> fyi i'm jira gardening fss and then UIO issues
[12:52:08 CST(-0600)] * jhung_afk just spilled coffee all over his desk. Mocha mouse anyone?
[12:59:38 CST(-0600)] <anastasiac> jhung, sorry for the late response - I was away from my desk. Docs are in ok shape - all tasks have someone assigned.
[13:02:27 CST(-0600)] <jhung> anastasiac: no prob. Then I'll go back to Jira gardening.
[13:02:38 CST(-0600)] <anastasiac> jhung, thanks so much for your help!
[13:02:40 CST(-0600)] <jhung> mlam: I'm continuing on inline edit jiras. Feel free to take on something else.
[13:02:44 CST(-0600)] <jhung> anastasiac: np.
[13:03:09 CST(-0600)] <mlam> jhung: ok, sounds good. thanks
[13:16:35 CST(-0600)] <heidi_> jhung what does this one mean? http://issues.fluidproject.org/browse/FLUID-1437
[13:16:58 CST(-0600)] <heidi_> what's springboard markup?
[13:18:09 CST(-0600)] <colinclark> Springboards were an attempt for us to create simple starting points for teaching people how to use our components, heidi_
[13:18:16 CST(-0600)] <colinclark> Dorky name--blame me
[13:18:17 CST(-0600)] <colinclark> (tongue)
[13:18:25 CST(-0600)] <colinclark> There's always been an interesting kind of tension with demos
[13:18:29 CST(-0600)] <colinclark> How much context should we show?
[13:18:41 CST(-0600)] <colinclark> Will the user get confused about the difference between the component and what the demo does?
[13:18:55 CST(-0600)] <colinclark> So Springboards were the start of us reworking our demos
[13:19:07 CST(-0600)] <heidi_> can you define springboard
[13:19:43 CST(-0600)] <colinclark> "A code example or starting point for developers to learn how to use a component"
[13:19:48 CST(-0600)] <colinclark> including simple CSS, HTML and JS
[13:19:57 CST(-0600)] <heidi_> how's it different than a demo?
[13:19:57 CST(-0600)] <colinclark> The term is long in disuse, as it should be (smile)
[13:20:06 CST(-0600)] <colinclark> Well, that's exactly my point
[13:20:09 CST(-0600)] <Bosmon2> Unlike the term "Proleptick Joinsets" (tongue)
[13:20:11 CST(-0600)] <colinclark> The question of demos gets fuzzy
[13:20:11 CST(-0600)] <heidi_> gotcha
[13:20:16 CST(-0600)] <colinclark> How much context?
[13:20:31 CST(-0600)] <colinclark> You know, like let's take the keyboard accessibility demo for example
[13:20:38 CST(-0600)] <colinclark> that shiny new one we just created
[13:20:45 CST(-0600)] <heidi_> mmhm
[13:21:07 CST(-0600)] <colinclark> I can actually imagine that a user might go to it and think "wow, Fluid makes an image browsing and rating component"
[13:21:21 CST(-0600)] <colinclark> On the other hand, it's a nice way of showing our keyboard plugin in a real-world situation
[13:21:31 CST(-0600)] <colinclark> All of our old demos used to be too "real world"
[13:21:41 CST(-0600)] <colinclark> Bosmon2: You mean Promises, right? (tongue)
[13:21:50 CST(-0600)] <heidi_> right, i see
[13:21:55 CST(-0600)] <colinclark> So Springboards were us making super-stripped down demos
[13:22:09 CST(-0600)] <colinclark> Most of the demos you saw in the 1.1-1.2 era were so-called Springboards
[13:22:10 CST(-0600)] <heidi_> less real worldy
[13:22:20 CST(-0600)] <heidi_> ah
[13:22:21 CST(-0600)] <colinclark> No worldly
[13:22:30 CST(-0600)] <colinclark> So, interestingly, we seem to be going back towards a bit more context
[13:22:36 CST(-0600)] <colinclark> I think ultimately it's a real art
[13:22:40 CST(-0600)] <heidi_> colin, is fss's goal to skin all of the components someday?
[13:22:57 CST(-0600)] <colinclark> How much "real worldness" will help developers understand the power of components, without getting in their way of seeing how simple they are
[13:22:58 CST(-0600)] <heidi_> or rather, the components to have specific skins
[13:23:11 CST(-0600)] <heidi_> yeah tricky line
[13:23:35 CST(-0600)] <colinclark> heidi_: Definitely one of the things we need to look at for 1.4 or 1.5 (not entirely sure yet which one) is a default Infusion theme
[13:23:47 CST(-0600)] <colinclark> Something hot, which will apply to all our components by defaults, and which we will use in our demos as well
[13:23:50 CST(-0600)] <heidi_> i'm just seeing issues like "Create skins for component: Pager"
[13:24:01 CST(-0600)] <colinclark> I think I would toss all of these
[13:24:07 CST(-0600)] <heidi_> yeah
[13:24:12 CST(-0600)] <colinclark> and we'll file more focused JIRAs as we start to build up our to do list for 1.4 and 1.5
[13:24:20 CST(-0600)] <colinclark> Which brings me to something I wanted to mention to you anyway
[13:24:43 CST(-0600)] <colinclark> I'm hoping next week that you, me, and Justin can sit down and start do some planning and triage of bugs and features for FSS
[13:25:12 CST(-0600)] <heidi_> colinclark that'd be great. i'm in wednesdays. and i think going through these issues now will help set up for that
[13:25:18 CST(-0600)] <jhung> mlam: do you know if this was ever addressed? http://issues.fluidproject.org/browse/FLUID-1955
[13:25:21 CST(-0600)] <colinclark> I'd like to take the lists we've got in JIRA, along with the list Unicon gave us, and see if we can put together a nice, step-by-step plan for making FSS awesome
[13:25:28 CST(-0600)] <colinclark> heidi_: Yep, exactly.
[13:25:39 CST(-0600)] <heidi_> sounds good
[13:25:43 CST(-0600)] <colinclark> I'd also really like to try to bring mpollizotti and Gary into the process as much as we can
[13:25:51 CST(-0600)] <colinclark> either just by giving us advice and feedback, or by helping with a bit of the work
[13:25:55 CST(-0600)] <colinclark> athena, too
[13:25:57 CST(-0600)] <colinclark> she's a big FSS user
[13:26:09 CST(-0600)] <heidi_> colinclark in terms of timelineing.. i know still fuzzy but will FSS work happen after the UIO 1.4 work?
[13:26:14 CST(-0600)] <colinclark> And they've got cool stuff, too, I think. Extensions to FSS that we might want to roll into the core
[13:26:24 CST(-0600)] <colinclark> FSS work will happen first thing for Infusion 1.4
[13:26:34 CST(-0600)] <heidi_> okay cool
[13:26:40 CST(-0600)] <colinclark> You missed a nice chat yesterday at the dev meeting where I walked people through the plan as it is emerging
[13:26:57 CST(-0600)] <heidi_> ah yes, there's a wiki page for the planning too right
[13:27:01 CST(-0600)] <colinclark> In the meantime, jessm has done a nice job of putting up some notes in the wiki: http://wiki.fluidproject.org/display/fluid/Infusion+Roadmap+Draft+1.3.1+-+1.5
[13:27:05 CST(-0600)] <colinclark> yep
[13:27:06 CST(-0600)] <heidi_> cool
[13:27:24 CST(-0600)] <colinclark> So, we've found having a "theme" for a release really helpful
[13:27:27 CST(-0600)] <heidi_> so this says UIO redesign is 1.3.1
[13:27:51 CST(-0600)] <colinclark> heidi_: That's the design work--research, wireframes, paper prototyping and testing
[13:27:58 CST(-0600)] <heidi_> gotcha
[13:28:08 CST(-0600)] <colinclark> jessm and I have structured things so that the design team gets to be out front a bit more
[13:28:15 CST(-0600)] <heidi_> makes sense
[13:28:15 CST(-0600)] <colinclark> More time early on to experiment and do design work
[13:28:23 CST(-0600)] <mlam> jhung: I'm pretty sure that JIRA hasn't been handled yet.... as the inline edit is still toggling between display and edit modes using hide/show
[13:28:32 CST(-0600)] <colinclark> and then we come along as the designs start to shape up, and we do some implementation, and we iterate again
[13:28:39 CST(-0600)] <heidi_> looks good!
[13:28:58 CST(-0600)] <jhung> mlam: thanks. I'll leave it open and mark it as affecting Infusion 1.3
[13:29:04 CST(-0600)] <colinclark> So, the theme for Infusion 1.4, heidi_, will be "Personalization and Preferences"
[13:29:11 CST(-0600)] <mlam> ok, thanks.
[13:29:22 CST(-0600)] <heidi_> colinclark nice, i like it
[13:29:30 CST(-0600)] <colinclark> We want a production-ready, end-to-end solution for users to be able to specify, at very least, styling and layout preferences
[13:29:31 CST(-0600)] <heidi_> we had such fun talking about UIO yesterday
[13:29:32 CST(-0600)] <colinclark> (with UI Options)
[13:29:43 CST(-0600)] <colinclark> So FSS has to be all ready and shiny for that
[13:29:55 CST(-0600)] <heidi_> woo, ok
[13:30:06 CST(-0600)] <colinclark> And then we're going to work on storing user preferences out in the cloud or locally in the user's browser
[13:30:08 CST(-0600)] <colinclark> (or both)
[13:30:27 CST(-0600)] <colinclark> and then show that this stuff works seamlessly by tying it into the Inclusive Learning Handbook, our Web sites, and any partners who are interested
[13:30:36 CST(-0600)] <colinclark> FLOE partners like some of the OER sites
[13:30:37 CST(-0600)] <heidi_> exciting work
[13:30:46 CST(-0600)] <colinclark> or even uPortal if Gary and athena are interested in it
[13:30:51 CST(-0600)] <colinclark> So that's that (smile)
[13:30:58 CST(-0600)] <heidi_> thanks for the info colin
[13:32:00 CST(-0600)] * athena looks up
[13:33:12 CST(-0600)] <athena> what're we talking about? UI options?
[13:35:57 CST(-0600)] <colinclark> athena: FSS and UI Optoins
[13:36:10 CST(-0600)] <colinclark> The important part is just that we're shaping up a plan for Infusion 1.4
[13:36:17 CST(-0600)] <colinclark> which will include huge improvements to FSS
[13:36:20 CST(-0600)] <athena> oh! hurray!
[13:36:23 CST(-0600)] <colinclark> based on all of your awesome feedback
[13:36:34 CST(-0600)] <athena> oh terrific! i'm sure matt will be thrilled to hear that (smile)
[13:36:53 CST(-0600)] <colinclark> And then our goal is to have styling and layout transformation with UI Options all production-worthy and ready to integrate into any app
[13:37:00 CST(-0600)] <athena> oh interesting
[13:37:05 CST(-0600)] <colinclark> I'm really hoping Matt might want to get involved
[13:37:09 CST(-0600)] <athena> i saw something about having those preferences be browser-persisted?
[13:37:13 CST(-0600)] <colinclark> even if just testing out what we've got and giving us helpful advice
[13:37:19 CST(-0600)] <colinclark> but he seems like he's used FSS a ton
[13:37:48 CST(-0600)] <athena> yeah, he's got a lot of great practical experience with it, and he really understands that stuff
[13:38:04 CST(-0600)] <colinclark> As for browser-persisted preferences, yep. We're looking at the range of options for how users might want to store and hold onto their personal preferences
[13:38:11 CST(-0600)] <athena> interesting.
[13:38:19 CST(-0600)] <athena> i wonder what we'd want to do for uportal
[13:38:23 CST(-0600)] <colinclark> In the long run, the goal would be to build this into the HTML 5 local data storage spec or something similar
[13:38:42 CST(-0600)] <colinclark> I think we'll also do some kind of "cloud-based" preferences storage
[13:38:42 CST(-0600)] <athena> probably would want preferences saved to the database-persisted user profile/layout rather than in the browser
[13:38:54 CST(-0600)] <athena> that way you can take them with you if you log in on another computer
[13:38:57 CST(-0600)] <colinclark> a.k.a. some server that works with a single sign-on solution that multiple apps can share
[13:39:06 CST(-0600)] <colinclark> athena: yep, I think you're right
[13:39:07 CST(-0600)] <athena> interesting
[13:39:15 CST(-0600)] <colinclark> I see preferences storage as having three or four layers
[13:39:21 CST(-0600)] <colinclark> 1. App-specific storage
[13:39:27 CST(-0600)] <colinclark> That's what you're talking about for uPortal
[13:39:29 CST(-0600)] <athena> yep
[13:39:34 CST(-0600)] <colinclark> store them along with the user layout, and you're done
[13:39:45 CST(-0600)] <athena> but getting a default from a central store could be interesting as well
[13:39:55 CST(-0600)] <colinclark> 2. A shared but trustworthy central store (maybe with OpenID?)
[13:40:23 CST(-0600)] <colinclark> 3. HTML5 local data storage, but in a way that can be accessed safely across domains (via a browser plugin to start, but ultimately put into the spec, we hope)
[13:40:40 CST(-0600)] <colinclark> 4. On portable, removable media like a USB thumbdrive
[13:40:51 CST(-0600)] <colinclark> I think for most Web-based cases, #4 is unncessary
[13:42:23 CST(-0600)] <athena> sounds pretty cool (smile)
[13:46:59 CST(-0600)] <heidi_> michelled_ do you know the state of this: http://www.google.com/hostednews/afp/article/ALeqM5joUqvUkY100McBAZyzY5d74ko0lA?docId=CNG.e83fdace708a2d6c4a7b95b21e5ed3a6.4b1
[13:47:02 CST(-0600)] <heidi_> oops
[13:47:08 CST(-0600)] <heidi_> this one: http://issues.fluidproject.org/browse/FLUID-1876
[13:51:13 CST(-0600)] <colinclark> heidi_: It can be closed
[13:51:19 CST(-0600)] <heidi_> k
[13:53:39 CST(-0600)] <heidi_> jhung do you have ie6
[13:54:08 CST(-0600)] <jhung> No. I have IE7.
[13:54:12 CST(-0600)] <heidi_> k
[13:54:14 CST(-0600)] <jhung> actually. I lie.
[13:54:17 CST(-0600)] <jhung> I do have IE6
[13:54:33 CST(-0600)] <jhung> heidi_: need something tested?
[13:54:46 CST(-0600)] <heidi_> jhung could you test something quick for me when you have a sec? http://issues.fluidproject.org/browse/FLUID-2483 , scroll to bottom to reproduce
[13:55:28 CST(-0600)] <jhung> heidi_: k gimme a sec.
[13:58:12 CST(-0600)] <jhung> heidi_: it's gone. I posted a comment.
[13:58:21 CST(-0600)] <heidi_> jhung thanks so much!
[13:58:27 CST(-0600)] <jhung> heidi_: np.
[13:58:30 CST(-0600)] <heidi_> ill close it
[13:58:34 CST(-0600)] <jhung> yup
[13:59:30 CST(-0600)] <jhung> btw, what are we doing about bug affecting unsupported browsers like Opera 9 and FF2? If I test them in Opera 12 and FF3 and bug is not present, then can they be closed?
[13:59:49 CST(-0600)] <heidi_> good question , i'm debating closing an FF2 issue
[14:01:47 CST(-0600)] <mlam> colinclark: did you want to go through the list of uploader fixes for the 1.3.1 release?
[14:02:56 CST(-0600)] <colinclark> I'm in the midst of something at the moment, mlam
[14:03:03 CST(-0600)] <colinclark> when are you here until today?
[14:03:12 CST(-0600)] <mlam> i'm here until 5
[14:03:30 CST(-0600)] <colinclark> maybe tomorrow morning?
[14:03:36 CST(-0600)] <mlam> ok, sounds good
[14:05:49 CST(-0600)] <jhung> jameswy: do you feel satisfied that we have addressed this? http://issues.fluidproject.org/browse/FLUID-2075
[14:15:46 CST(-0600)] <jameswy> jhung: Yes.
[14:16:12 CST(-0600)] <jhung> ty
[14:40:34 CST(-0600)] <heidi_> jhung got another IE6 if you have a second
[14:40:42 CST(-0600)] <jhung> sure
[14:43:52 CST(-0600)] <heidi_> jhung : http://issues.fluidproject.org/browse/FLUID-3626
[14:49:02 CST(-0600)] <jhung> Commented. Seems to affect all demos now. (sad)
[14:49:51 CST(-0600)] <jhung> Good thing we're redesigning the portal soon.
[14:51:48 CST(-0600)] <heidi_> jhung ack.
[14:52:06 CST(-0600)] <heidi_> thanks for testing that
[14:52:12 CST(-0600)] <jhung> heidi_: np. I posted a comment to the Jira.
[14:52:14 CST(-0600)] <jessm> anastasiac: ping
[14:52:18 CST(-0600)] <heidi_> thanks!
[14:52:45 CST(-0600)] <anastasiac> jessm: polo
[14:52:58 CST(-0600)] <jessm> anastasiac: woah, you made my cursor jump by responding
[14:53:11 CST(-0600)] <jessm> anastasiac: would you be so kind as to kill the link on the build page to the FE demo?
[14:53:11 CST(-0600)] <anastasiac> I have magical powers
[14:53:31 CST(-0600)] <anastasiac> jessm, I will attempt to do so.
[14:53:40 CST(-0600)] <jessm> anastasiac: what happened to the magic?
[14:53:51 CST(-0600)] <anastasiac> it's always there
[14:54:24 CST(-0600)] <jessm> anastasiac: and by the engage demos i expect I mean all three links
[14:54:37 CST(-0600)] <anastasiac> k
[14:54:54 CST(-0600)] <jessm> anastasiac: esp. since 2 out of 3 throw errors
[14:57:55 CST(-0600)] <anastasiac> jessm: done - please confirm
[14:58:21 CST(-0600)] <jessm> anastasiac: roger Roger
[14:59:02 CST(-0600)] <anastasiac> but jessm: should we perhaps be figuring out why the links are broken, and fixing it?
[14:59:20 CST(-0600)] <jessm> anastasiac: did you read colin's reply?
[14:59:45 CST(-0600)] <jessm> also, the FE components come onto the roadmap soon, so this will get kicked up again
[14:59:56 CST(-0600)] <anastasiac> no - reply where? in the channel? what time?
[15:00:07 CST(-0600)] <heidi_> michelled_ what does this one mean? http://issues.fluidproject.org/browse/FLUID-1656
[15:00:21 CST(-0600)] <jessm> anastasiac: on the list
[15:00:30 CST(-0600)] <colinclark> one of michelled_
[15:00:35 CST(-0600)] <anastasiac> ah. now I see your email, but no reply yet
[15:00:36 CST(-0600)] <colinclark> 's famously terse JIRAs
[15:01:12 CST(-0600)] <heidi_> colinclark any ideas?
[15:01:17 CST(-0600)] <colinclark> yeah
[15:01:34 CST(-0600)] <colinclark> michelled_ is probably better to explain it, but she may be distracted with CollectionSpace
[15:01:53 CST(-0600)] <heidi_> someway to let uioptions know the features of a skin or something?
[15:02:12 CST(-0600)] <michelled_> ya, I was getting an awesome tour of the new confirmation dialog in cspace
[15:05:41 CST(-0600)] <michelled_> heidi_: I don't actually know too many details for that one. it was something that fj was thinking about and we hadn't fleshed out what it would mean in practice yet. The overall idea is that ui enhancer transforms the UI based on people's preferences but sometimes it doesn't do a great job of the transformation. The hinting was intended to add some more context for ui enhancer so that it could do a better job.
[15:05:56 CST(-0600)] <michelled_> I think he got a start on this with the linearization features
[15:06:28 CST(-0600)] <heidi_> interesting...
[15:08:39 CST(-0600)] <michelled_> I think concretely it would be realized as classnames in the DOM.
[15:10:00 CST(-0600)] <michelled_> I think we talked about two different types of hints - ones that are similar to ARIA (perhaps ARIA has grown enough that it provides enough context itself) in that they are known markers
[15:10:55 CST(-0600)] <michelled_> I'm not sure I'm being clear here but basically ARIA roles are what I'm thinking of. communicating to the ui enhancer what a thing is which would help when transforming it
[15:11:10 CST(-0600)] <colinclark> The idea of a hint reminds me a lot of what Instapaper offers to site developers
[15:11:23 CST(-0600)] <colinclark> don't know if you guys know Instapaper, michelled_ and heidi_
[15:11:36 CST(-0600)] <colinclark> It saves web pages for later
[15:11:44 CST(-0600)] <colinclark> in a more readable form, stripping out all the extra stuff
[15:12:18 CST(-0600)] <colinclark> And if it does a poor job of your site, you can give it some extra "hints"
[15:12:20 CST(-0600)] <colinclark> http://www.instapaper.com/publishers
[15:12:25 CST(-0600)] <heidi_> michelled_ ah, like a hint is a semantic tag or something
[15:12:30 CST(-0600)] <michelled_> the second type would be a way for integraters to tell the ui enhancer what do to with a something - like perhaps an fss-ignore class?
[15:12:40 CST(-0600)] <colinclark> In this case, A couple of XPaths point out the important part of your content
[15:12:53 CST(-0600)] <colinclark> In our case, it would either be some extra classes put into the DOM by the author
[15:12:54 CST(-0600)] <heidi_> colin this is neat
[15:13:13 CST(-0600)] <colinclark> or more like, a series of jQuery selectors that would match with additional information UI Enhancer wouldn't otherwise know about
[15:13:22 CST(-0600)] <michelled_> ha, it has instapaper-ignore (smile)
[15:14:49 CST(-0600)] <michelled_> colinclark, heidi_: I think to answer your original question that JIRA can be closed and we can open the more specific ones when we know about them.
[15:15:08 CST(-0600)] <heidi_> will do
[15:16:55 CST(-0600)] <michelled_> there were a bunch of UI Options JIRAs that were opened that came out of some brainstorming sessions. I think it was the wrong place to put them - they should have gone into some other format.
[15:18:05 CST(-0600)] <heidi_> michelled_ good they were documented regardless. it's a cool idea!