| Time |
Nick |
Message |
| 00:46 |
|
dbwells joined #evergreen |
| 00:46 |
|
Stompro joined #evergreen |
| 01:03 |
|
_bott_ joined #evergreen |
| 01:42 |
|
StomproJ joined #evergreen |
| 07:56 |
|
rjackson_isl joined #evergreen |
| 08:12 |
|
ericar joined #evergreen |
| 08:14 |
|
graced joined #evergreen |
| 08:17 |
|
Dyrcona joined #evergreen |
| 08:24 |
|
TaraC joined #evergreen |
| 08:26 |
|
mrpeters joined #evergreen |
| 08:28 |
|
mmorgan joined #evergreen |
| 08:28 |
|
RoganH joined #evergreen |
| 08:45 |
|
mdriscoll joined #evergreen |
| 09:00 |
|
maryj joined #evergreen |
| 09:11 |
dbs |
kmlussier: http://mlnc4.mvlcstaff.org/ (linked from demo evergreen servers page) seems to not be responding |
| 09:27 |
jeff |
...or responding with an HTTP 500 error after a while |
| 09:30 |
dbs |
jeff is more patient than me :) |
| 09:38 |
|
yboston joined #evergreen |
| 09:42 |
Dyrcona |
tsbere could probably fix it, but he's busy with something else at the moment. |
| 09:43 |
Dyrcona |
I probably could also, but ditto, and I'd have to figure out/remember how to get into that server. |
| 09:43 |
* tsbere |
isn't sure what branch(es) should be rigged on that vm anyway |
| 09:43 |
Dyrcona |
Well, there's that, but I figured services just need a kick. |
| 09:46 |
RoganH |
@hate reporter |
| 09:46 |
pinesol_green |
RoganH: But RoganH already hates reporter! |
| 09:49 |
Dyrcona |
Seems like you can't hate it enough. :) |
| 09:49 |
* Dyrcona |
is not very fond of it, either. |
| 09:52 |
RoganH |
I'm looking a nice simple SQL report I'm supposed to recreate in reporter and I know it'll be a hassle. |
| 09:54 |
|
julialima_ joined #evergreen |
| 09:59 |
dbs |
RoganH: that's pretty much why I decided to try and teach people SQL years back :) |
| 10:00 |
goood |
RoganH: when we get to the reports sprint of the web client, I plan to implement a "write your own template with SQL" feature ... doing that in xul would be Hard(tm), but much simpler with a fresh start |
| 10:00 |
RoganH |
goood: I look forward to that with great, great enthusiasm. |
| 10:01 |
RoganH |
dbs: I'm the only one with sql access for various reasons. |
| 10:03 |
dbs |
RoganH: oh yeah, that makes sense. I meant to other evergreen sites that have a person like you or me who would have access, but who needed an intro to SQL. |
| 10:03 |
RoganH |
dbs: gotcha |
| 10:03 |
dbs |
I felt really bad when a new librarian was all proud of himself for figuring out reports on his own, and I had to point out how flawed those reports were |
| 10:04 |
* goood |
makes a mental note: include a new permission to restrict access to that "closer to SQL" template UI... |
| 10:04 |
RoganH |
everything is a learning curve. I was looking at some old reports of mine yesterday and I was proud of them a few years ago and now I realize they were horrible. |
| 10:04 |
dbs |
counting deleted items, the ever-popular outer join by default, ... |
| 10:05 |
RoganH |
I still have plenty to learn but I feel like I at least have a grasp on knowing the scope of what I don't know. |
| 10:06 |
dbs |
so goood, I still don't understand what makes the web client development process any different than any other new feature development process |
| 10:07 |
dbs |
particularly with the latest merge. seems like that should be a good base on which to build feature branches. |
| 10:08 |
gsams |
goood++ #SQL writer in the client would be appreciated greatly! |
| 10:14 |
RoganH |
Let me echo that: |
| 10:14 |
RoganH |
goood++ |
| 10:14 |
dbwells |
Good morning all. The OPW group wishes to once again solicit some opinions about a few UI best practices and guidelines. |
| 10:16 |
dbwells |
julialima_ is also here, so please feel free to address her as well with any replies. |
| 10:16 |
julialima_ |
Good morning! |
| 10:16 |
mmorgan |
Good Morning! |
| 10:17 |
jeff |
good morning julialima_, dbwells! |
| 10:18 |
dbwells |
One thing we've been looking at recently is form design. The staff client by its nature has a lot of forms, so it's a fruitful area to consider, but also difficult, since different forms do different jobs. |
| 10:18 |
dbwells |
I'd like to start with the question of basic layout. |
| 10:19 |
dbwells |
In general, do we want to recommend a single column, a single row, or a multi-column/grid structure? And beyond the general cases, are there specific cases where we should deviate from the base style we select? |
| 10:20 |
dbwells |
Single column is very common, simple to implement, and also easy to understand. |
| 10:20 |
dbwells |
One example (though having it's own issues) would be the current patron editor. |
| 10:21 |
dbwells |
When I say "single row", I mean cases where the grouped elements are horizontal. One example of this in the current client is the item attributes editor. |
| 10:22 |
dbwells |
This was likely chosen over the vertical column layout to fit more on the screen. |
| 10:24 |
dbwells |
A multi-column or grid approach is a further attempt to maximize screen usage, but can be difficult to implement in a systematic and balanced way. |
| 10:26 |
dbs |
dbwells: Can you link to examples in webby, or screen shots? That would make things more concrete |
| 10:27 |
Dyrcona |
My boss may have a fit, but I'm looking at lp 957466 'cause it bit use pretty hard this week. |
| 10:27 |
pinesol_green |
Launchpad bug 957466 in Evergreen "overlaying a record from vandelay does not update editor/edit_date" (affected: 7, heat: 34) [Medium,Confirmed] https://launchpad.net/bugs/957466 |
| 10:28 |
Dyrcona |
berick in particular may want to comment on my comments. |
| 10:28 |
dbwells |
dbs: Sure, I'll grab some screen shots |
| 10:33 |
|
mllewellyn joined #evergreen |
| 10:41 |
dbwells |
Okay, here are some screen shots. |
| 10:42 |
dbwells |
I couldn't think of a true grid example in Evergreen, so I grabbed (a bad) one from the web: http://www.calvin.edu/library/images/form_layout_examples.png |
| 10:43 |
dbwells |
Notice we're focusing at this point on the arrangement of the *groups*, not the individual fields. |
| 10:49 |
dbs |
So, the grid seems nice from a potential screen-width responsiveness perspective |
| 10:50 |
dbs |
Single column should fit on any screen width. Presumably one could include an automatically generated table of contents to facilitate navigating it, if it's sectioned and scrolly. |
| 10:52 |
dbs |
flexbox should help with implementing the grid approach if that becomes a chosen direction |
| 10:52 |
phasefx |
it occurs to me there is another model, the google play cover art layout. X by Y grid, but X changes depending on screen width |
| 10:53 |
dbwells |
From my survey of various recommendations, there is a definite trend toward a single column recommendation. Opponents would say it wastes space and requires too much scrolling, while proponents would say that filling the screen is a false economy, since attention is limited anyway, so having less on the screen isn't a bad thing. |
| 10:54 |
dbwells |
dbs: If we go more with single column, I like your idea of a table of contents. |
| 10:54 |
dbs |
phasefx: that's what I was talking about with the screen responsiveness. |
| 10:55 |
phasefx |
dbs: roger that |
| 10:57 |
dbs |
single column also hopefully focuses on most common / most important stuff at the top, and could be refactored reasonably easily into a grid format later on assuming the properties are grouped inside <div>s or whatever, if so desired |
| 10:57 |
mmorgan |
I think one thing that needs to be considered is ease of navigation using the keyboard. Regardless of the layout, users should be able to tab from field to field in data entry forms. Tab order should be predictable. |
| 10:57 |
dbs |
mmorgan++ # yup, don't break tabbing! |
| 10:57 |
jeff |
mmorgan: i would hope that goes without saying, but mmorgan++ for saying it. |
| 10:58 |
dbwells |
Tab order predictability is a greater problem with a multi-dimensional layout. |
| 10:58 |
* jeff |
nods |
| 10:59 |
jeff |
down-then-over vs over-then-down |
| 10:59 |
jeff |
consistency is important there |
| 10:59 |
mdriscoll |
Dyrcona: I would be happy to test your branch when you get it done |
| 11:01 |
dbwells |
Okay, feel free to keep talking about layout, but we have more questions! :) |
| 11:01 |
jeff |
do the single row and grid examples allow presenting more information when you're looking at the "form" not because you're editing, but because you're reviewing / seeking information? item status single-row display vs item attribute editor single-row display being one example -- would we consider moving the item status display move to single column? |
| 11:03 |
dbwells |
jeff: That's a good point. I don't have a good answer, but I do think the concept of dual purpose display/edit screens should be carefully considered. |
| 11:05 |
julialima_ |
The next question concerns the style (CSS). Should we create a new style, leave the system defaults or "it depends"? |
| 11:06 |
dbwells |
jeff: So to your last question, I would say yes, we should consider that, but again, I have no answer for that right now :) |
| 11:07 |
dbs |
If we're talking webby, then there are at least some fixes required (e.g. lack of contrast when you click on one of the top-level menu items and the white text gets highlighted in light grey) |
| 11:08 |
dbs |
But I guess "it depends"; it's a broad question and I'm not sure about the scope |
| 11:08 |
dbwells |
Sorry, I think julialima_ mean's in the context of form elements specifically. |
| 11:08 |
dbwells |
s/mean's/means/ :P |
| 11:08 |
dbwells |
Otherwise, it is a very broad question indeed :) |
| 11:10 |
julialima_ |
Yes, form elements, sorry! |
| 11:10 |
dbs |
I guess my knee-jerk reaction would be to try and stick with the native HTML5 form elements where possible (so that mobile devices can automatically adapt to them, etc) |
| 11:12 |
dbwells |
I know some experts have advocated that deviating from the OS-styled form elements hurts usability. On the other hand, keeping them totally pure hurts design, particularly when OS elements are very styleized, or have greatly different sizes on different systems. |
| 11:12 |
dbs |
I'm not 100% sure if we're talking about getting rid of the old Dojo/dijit form elements or even older XUL form elements or what |
| 11:14 |
dbwells |
As things stand in webby, we're using Bootstrap CSS for our form elements. It provides a reasonable set of basic styles to keep things mostly similar looking across different systems. |
| 11:15 |
dbs |
So, the question is, should we override the default Bootstrap CSS for form elements in webby? |
| 11:17 |
dbwells |
I think the question is more whether we want to continue using styled form elements at all. Maybe everyone feels we should, but we thought we'd give any purists a chance to make a case. |
| 11:18 |
dbs |
I think as long as we're using the right @type on the <input> element (per https://developer.mozilla.org/en-US/docs/Web/HTML/Element/Input#Attributes), bootstrap will do roughly the right thing |
| 11:19 |
dbwells |
A deeper question would be whether we would entertain using custom form elements in cases where the CSS controls (which are limited) do not give us exact style/functionality we want. |
| 11:20 |
dbwells |
dbs: I think that is what you objected to with your knee-jerk reaction, right? |
| 11:21 |
dbs |
Can you make that hypothetical case more concrete with an example of where a more exact style/functionality would be desired? |
| 11:25 |
|
sandbergja joined #evergreen |
| 11:26 |
dbs |
I guess the answer in the abstract has to be "Sure, we would entertain using custom form elements where custom form elements are required". Just ensure the base types are checked first. |
| 11:29 |
dbwells |
It's become much less of an issue with CSS 3.0, so maybe the point is moot (if we think CSS 3.0 is viable at this point). But I am thinking more about cases where visual design might be contrary to standard form elements. |
| 11:31 |
|
bmills joined #evergreen |
| 11:31 |
dbwells |
Maybe not a great example, but consider the "star" in Gmail. It could have been a checkbox, but it isn't, and that is likely because Google would rather compromise the nature of the element rather than compromise what it looks like. (and ignoring CSS 3.0, probably for compatibility reasons, I don't know) |
| 11:32 |
dbwells |
Anyway, we've answered the bigger question of styled vs unstyled elements. |
| 11:33 |
dbwells |
Again, feel free to add more responses, but moving ahead. |
| 11:35 |
dbwells |
Forms vs "wizards": Do we need guidelines about when should we offer each? Should some forms (e.g. patron registration) perhaps be switchable? |
| 11:42 |
dbwells |
Some styles can also functionally be a hybrid of sorts. Let me pull up a mockup julialima_ created, one moment. |
| 11:46 |
dbwells |
So, ignoring details about particulars for labels or specific contents, a multi-screen layout like this: http://www.calvin.edu/library/images/patron_editor_multiscreen_mockup.png |
| 11:50 |
dbwells |
A layout like this could function like a wizard for patron creation, but still be usable for editing. |
| 11:51 |
dbwells |
Overall, is it a balanced enough approach? Can it reasonably apply to other forms, e.g. the item editor? |
| 11:54 |
jeff |
the patron editor used to be multi-page, with a Table of Contents of sorts on the side. |
| 11:55 |
jeff |
I'm not opposed to having that as an option again for interfaces where it may make sense. |
| 11:55 |
jeff |
The idea almost connects back to the earlier questions about single-column vs other options. |
| 11:55 |
dbwells |
Yes, it is another angle on the same problem. |
| 11:56 |
jeff |
One thing about the current patron editor is that it's often easy to get lost in the huge long single column. |
| 11:56 |
dbwells |
And man, I forgot all about the old patron editor. |
| 11:57 |
dbwells |
Yes, the current form certainly has some low hanging fruit for improvements. |
| 11:57 |
jeff |
And while more grouping / whitespace / padding can go a long way toward addressing the single column's issue of getting lost, this is another additional option. |
| 11:57 |
goood |
dbs: sorry, meetings. it's different because it's not "a pile of features", it's a HUGE PILE of infrastructure and a separate HUGE pile of features that require (and drive) all that infrastructure and are all interdependent. if the infrastructure parts were going directly into master, it might be possible to do feature branches, but even then, the interdependence causes a lot of overhead that doesn't pay off for just a few |
| 11:57 |
goood |
devs |
| 12:02 |
dbwells |
Well, it is past noon, so we need to wrap up the OPW discussion for today. Thanks to everyone who gave some input. To anyone who comes by this discussion late, please do ping me or julialima_ with any responses you might have. |
| 12:03 |
julialima_ |
Thank you very much for your time! |
| 12:07 |
jeff |
julialima_: thank you! |
| 12:07 |
jeff |
dbwells: thank you! |
| 12:12 |
jboyer-isl |
julialima_++ |
| 12:12 |
jboyer-isl |
dbwells++ |
| 12:12 |
jboyer-isl |
Thanks for your efforts, I wish I had time to participate more in these discussions. |
| 12:14 |
dbs |
goood: well, you'll certainly ensure that it stays a few devs that way. then the rest of the devs will take another year or so to figure out how to contribute effectively to it |
| 12:19 |
|
kitteh_ joined #evergreen |
| 12:36 |
|
maryj joined #evergreen |
| 12:38 |
goood |
dbs: or they could just consider the "collab" branch as the "master" to target, and submit branches against that. not seeing the difference, really |
| 12:41 |
dbs |
Right. So why aren't bug fixes and small features being merged to master on a regular basis again? |
| 12:42 |
goood |
dbs: because folks don't test (save kmlussier) or merge, and I get smacked whenever I merge my own code, and get the side eye when I merge my coworkers' code without further review |
| 12:44 |
goood |
s/further review/non-esi review, for whatever personal reasons various folks may have/ |
| 12:49 |
|
nhilton joined #evergreen |
| 12:57 |
|
bmills joined #evergreen |
| 13:09 |
mrpeters |
Alrighty guys -- I'm in Action/Trigger hell and have come to beg for mercy! See http://pastie.org/9945103 -- an event_def to mark an item lost 3 hours after it goes overdue. Nothing fancy, pretty similiar to the stock 90 Day Lost notice. Each time the event runs, it ends with a state 'error' but I'm struggling to find more information about what caused the error. Pertinent osrfsys logs are at http://pastie.org/private/l62y4g3wodwvxhw2iwrdg -- Eve |
| 13:10 |
mrpeters |
I keep wanting to hone in on the "WARN" message that is frequent, but it seems to occur with every A/T event run, even those that work, so I'm not sure its relevant. |
| 13:10 |
pinesol_green |
[evergreen|Dan Scott] LP#1421673 Typo in webby: "Databse ID" - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=91a0e5c> |
| 13:20 |
Dyrcona |
mdriscoll: Now's your chance. |
| 13:20 |
Dyrcona |
http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/dyrcona/lp957466_vl_update_edit_date |
| 13:23 |
Dyrcona |
remingtron++ |
| 13:23 |
|
eeevil joined #evergreen |
| 13:23 |
|
sarabee joined #evergreen |
| 13:34 |
jeffdavis |
mrpeters: anything in your postgres logs? you've got a transaction rolling back right at the end there, just after trying to retrieve circ 1936 |
| 13:35 |
|
bmills joined #evergreen |
| 13:35 |
mrpeters |
jeffdavis: yeah -- i saw the rollbacks happen but i may have to bump the logging because i didnt see anything specificly relating |
| 13:35 |
mrpeters |
im going to go reset it, and tail them again |
| 13:48 |
mdriscoll |
Dyrcona: I will take a look and leave comments on lp |
| 13:48 |
Dyrcona |
mdriscoll: Thanks. You can sign off, too, if you like. :) |
| 13:51 |
Dyrcona |
mdriscoll: Don't forget that it's the top two commits on the branch. |
| 13:52 |
mdriscoll |
Dyrcona: ok thanks. |
| 13:55 |
|
mdriscoll left #evergreen |
| 13:58 |
dbwells |
Dyrcona: mdriscoll: I know remingtron was working on a branch last week to address berick's concerns on that bug. remingtron is out today, and I am not sure where he was at on it, but I am sure he'd be happy to help review this as well when he comes back Monday. |
| 14:00 |
Dyrcona |
Don't mean to step on anyone's toes, but I didn't know he was going to look at the Perl code. |
| 14:06 |
dbwells |
Dyrcona: It's no problem. I don't imagine he was doing anything substantially different, since your changes look right to me. I just thought I'd speak up since he wasn't around, and he can comment more intelligently on the branch than I can :) |
| 14:06 |
Dyrcona |
OK. |
| 14:13 |
dbwells |
My sense when he mentioned it last week was that he felt obligated to work on it since he had already done some work on it. My guess is he'll be very happy to see you've completed it. |
| 14:15 |
Dyrcona |
I felt obligated to work on it when a Backstage import busted up someone's work. :) |
| 14:15 |
Dyrcona |
That's cool. Collaboration is nice. |
| 14:24 |
Dyrcona |
While testing that change, I noticed something unusual. |
| 14:25 |
Dyrcona |
Any time I typed a key in the marc editor, regular or flat text, while editing a record to import, a JavaScript error window would pop up. |
| 14:26 |
Dyrcona |
TypeError: tab is undefined |
| 14:26 |
Dyrcona |
Still doing it, actually. |
| 14:26 |
Dyrcona |
MARC edit works fine on regular bibs. |
| 14:27 |
Dyrcona |
Guess I'll do a git clean and see what happens. |
| 14:27 |
kmlussier |
dbs: Thanks for letting me know about mlnc4. I'll fix it up now. |
| 14:28 |
dbwells |
Dyrcona: I saw that too, when testing master with a 2.7 client. I know it stems from some changes ldw wrote a while back, and I thought it might be related to me needing a new client. |
| 14:28 |
dbwells |
Are you seeing it with a master client? |
| 14:28 |
Dyrcona |
Yes. |
| 14:29 |
Dyrcona |
My script builds a fresh client when I build all of Evergreen. |
| 14:29 |
Dyrcona |
Guess that's a bug. |
| 14:29 |
Dyrcona |
If it happens after my current build, I'll file it. |
| 14:30 |
dbwells |
Ok, yes, sounds like it. Let me see if I still have the original bug open so I can get you the number for it. |
| 14:35 |
dbwells |
Dyrcona: I think this commit was supposed to fix it (and it also mentions the two bugs where this code was getting tracked): 64fcd3095f3 |
| 14:35 |
pinesol_green |
[evergreen|Liam Whalen] LP1282277_LP1282286_Unitialized_Vars_FIx - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=64fcd30> |
| 14:35 |
dbwells |
Don't know how much that will help, but there you go. |
| 14:35 |
|
ToeKnee joined #evergreen |
| 14:36 |
|
bmills joined #evergreen |
| 14:40 |
|
chick joined #evergreen |
| 14:42 |
Dyrcona |
dbwells: Thanks that saves me some time trying to find it. |
| 14:43 |
|
Tony__ joined #evergreen |
| 14:45 |
|
Tony__ left #evergreen |
| 14:46 |
|
akilsdonk joined #evergreen |
| 14:50 |
Dyrcona |
Hmmm. I have that commit, so something about it must still be wrong. |
| 14:53 |
kmlussier |
dbs / eeevil: Would it be worthwhile to discuss the web client merging at the next dev meeting? I don't know what the answer is, but I personally would love to see the code make it into master faster. |
| 14:54 |
kmlussier |
One thing I'm up against is that I have a few people on hand to help test the circ changes, but we aren't geared up to test cataloging yet. However, I don't really know if the other circ code in that collab branch is dependent on some of the cataloging features that come before it. |
| 14:55 |
kmlussier |
So signoffs there may not be helpful. |
| 14:56 |
kmlussier |
And mlnc4.mvlcstaff.org is up and running again. |
| 14:57 |
* kmlussier |
should add something to her calendar to update it monthly. |
| 15:03 |
Dyrcona |
Well, the diff isn't telling me much, and neither is JavaScript console. |
| 15:03 |
Dyrcona |
I may have to call on Venkman. |
| 15:04 |
Dyrcona |
If he's still around somewhere. |
| 15:24 |
|
chick joined #evergreen |
| 15:25 |
kmlussier |
@hate blizzards |
| 15:25 |
pinesol_green |
kmlussier: The operation succeeded. kmlussier hates blizzards. |
| 15:30 |
mmorgan |
@hate blizzards |
| 15:30 |
pinesol_green |
mmorgan: The operation succeeded. mmorgan hates blizzards. |
| 15:33 |
kmlussier |
@whocares blizzards |
| 15:33 |
pinesol_green |
kmlussier and mmorgan hate blizzards |
| 15:35 |
dbs |
kmlussier++ |
| 15:36 |
kmlussier |
dbs: I'm assuming that wasn't in reaction to my hate of blizzards. ;) |
| 15:37 |
kmlussier |
I always wonder if dbs thinks we're a bunch of whiners when we complain about snow in here. Given the amount of snow he sees in a normal year. |
| 15:39 |
Dyrcona |
Blizzards makes good games. |
| 15:39 |
Dyrcona |
Blizzard, even. |
| 15:39 |
Dyrcona |
;) |
| 15:44 |
dbs |
I think you've had way more snow than we've had. We just specialize in cold. |
| 15:57 |
kmlussier |
Yeah, well, I'm just as likely to whine about the cold as about snow. |
| 15:59 |
mmorgan |
We have both right now :) |
| 16:00 |
* Dyrcona |
dreams of Waimarama beach...... |
| 16:02 |
|
nhilton joined #evergreen |
| 16:05 |
|
julialima_ left #evergreen |
| 16:22 |
kmlussier |
berick: Have you set a meeting date yet? |
| 16:37 |
kmlussier |
@quote random |
| 16:37 |
pinesol_green |
kmlussier: Quote #94: "<bshum> we should do something about those cupcakes - they're going to go to waste" (added by csharp at 05:57 PM, September 25, 2014) |
| 16:38 |
kmlussier |
bshum does love his cupcakes |
| 17:04 |
|
nhilton joined #evergreen |
| 17:09 |
|
artunit joined #evergreen |
| 17:10 |
kmlussier |
Must be Friday afternoon. I had two client windows open, and I tried testing the new feature on the system that did not have the code loaded. Explains why it didn't work. |
| 17:13 |
|
mmorgan left #evergreen |
| 18:13 |
|
mrpeters left #evergreen |
| 18:20 |
|
dreuther joined #evergreen |
| 18:23 |
bmills |
Exhibitor and sponsorship opportunity pages for the 2015 conference are updated now at http://evergreen-ils.org/conference/eg15/ |
| 21:11 |
|
bmills joined #evergreen |
