Hi,<br><br><div class="gmail_quote">On 25 June 2012 16:09, Tseng-Planas, Alice <span dir="ltr"><<a href="mailto:atseng@it.ucla.edu" target="_blank">atseng@it.ucla.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="font-size:14px;font-family:Calibri,sans-serif;word-wrap:break-word">
<div>Hi Martin,</div><div class="im">
<span>
<div><br>
</div>
<div>I have a couple of comments/question on your wireframes:</div>
<div><br>
</div>
<div> - I see text annotations (yellow boxes corresponding to the red numbers on the wireframe) in the PDF on the first slide, but not subsequent ones. Is that intentional or has something gone wrong?</div>
</span>
<div><br>
</div>
</div><div>No nothing gone wrong. Sorry about that- I just had to stop last night because I needed to work on other projects but plan to finish annotations later this week.</div></div></blockquote><div><br></div><div>That's cool. I think it was pretty self-explanatory anyway for the most part, just wanted to make sure I hadn't missed anything.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="font-size:14px;font-family:Calibri,sans-serif;word-wrap:break-word"><div> Realized this first pass was taking much longer than I planned for and wanted to get something
out to you rather than wait. I just went ahead and marked all the annotation points so you could see the areas that I thought needed further clarification this is a weakness of wireframes; some of this would be easier in conversation and white boarding,
me thinks.</div></div></blockquote><div><br></div><div>I think it's worked pretty well so far, actually.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="font-size:14px;font-family:Calibri,sans-serif;word-wrap:break-word"><div class="im">
<span>
<div> - Would it be better if help was an overlay rather than a separate tab? This would allow it to be called up from multiple pages (mapper, file manager as well as control panel), and maybe feel a bit less like switching back and forth between help view
and the control panel proper.</div>
</span>
<div><br>
</div>
</div><div>Ah right. I think the "help tab" I'm distinguishing as a "global help resources page/section" -- I figured since so many of the complaints from the survey stemmed from people getting confused by the existing documentation they found online it could be
a helpful later feature to add a FAQ/tutorial style links so the new user has a one-stop-shop to accurate information. This is distinguished from "rules help" which is still preserved (your diazo cheat sheet) in the theme mapper as an overlay. Wondering if
this is confusing but I agree with you that the cheat sheet is better off as an overlay. Does that logic make sense?</div></div></blockquote><div><br></div><div>Right now, mainly to rationalise work/maintenance of this, I'm leaning towards the user guide you've seen a first draft of being available to call up on each screen with deep-links to relevant sections as appropriate.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="font-size:14px;font-family:Calibri,sans-serif;word-wrap:break-word"><div class="im"><span>
<div> - It may be quite hard to do a theme preview in an efficient, cross-browser way. I'll investigate. Do you think it might work to use the same basic layout on the control panel home page, but without a preview, just title/description?</div>
</span>
<div><br>
</div>
</div><div>Sure, anything is possible. It's good to know what your real dev constraints are we can rework based on that. </div></div></blockquote><div><br></div><div>The problem is that a theme is an HTML file, so the only way to render that in the browser is in an iframe, but scaling it down is virtually impossible. We could ask theme authors to upload screenshots of their themes, but I fear they just wouldn't in most cases.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="font-size:14px;font-family:Calibri,sans-serif;word-wrap:break-word"><div>The mock I sent you was a radical departure to give you another look at the problem. I think the core issues that the group discussed was balancing
2 tensions: their desire to have everything that is related to a task in one place and yet not be overwhelmed by a wall of text data and action buttons. Another solution (if that's workable with your constraints) is to have some closable panels and drawers
to minimize some secondary actions as a way to cut down on visual noise. Let me know if the image preview is a no-go and I can take another stab at reconfiguring a text-only based output.</div></div></blockquote><div><br>
</div><div>I actually like the 'tile' based approach. I think it solves the "row of buttons" issue with the table layout, which I was never very happy with. I just think maybe we need the tile to contain just title/description and not a thumbnail, although I'd like to try to figure out if we can get one in there.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="font-size:14px;font-family:Calibri,sans-serif;word-wrap:break-word"><div class="im"><span>
<div> - Drag-and-drop for theme activation is cool, but in case we can't make it work easily, is an explicit button action on the tile for each theme OK?</div>
</span>
<div><br>
</div>
</div><div>Yep. Same as above. I think if you're not concerned with scale (how many themes a user may be saving) a simple drop-down list picker or a column of radio buttons for selection will work. Or even another action as an inline. The deal with inline is that
too many 2ndary inline actions often cause users to complain that the interface is cluttered but, again it's a matter of scale -- and sometimes layout and whitespace can help a bit.</div></div></blockquote><div><br>
</div><div>I kind of imagine people will have at most a few themes, and probably quite often only one or two. I'm not sure we need to optimise for the case where people have dozens.</div><div><br></div><div>My current thinking is that we start with the tiles layout without thumbnails, and with an explicit activate/deactivate button that causes the relevant theme to be highlighted. Drag-and-drop and thumbnailing can then be future enhancements. That's mainly just to get something shippable in a reasonable time, as 4.3 merge deadline is drawing near.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="font-size:14px;font-family:Calibri,sans-serif;word-wrap:break-word"><div class="im"><span>
<div> - Are you happy with the file preview at the bottom of the file manager tree/edit panes? It doesn't appear in the wireframes. Note: you need to open an HTML file to see it.</div>
</span>
<div><br>
</div>
</div><div>Ah yes I removed those since more than one person from the group complained that they didn't see the need for it. I, personally just removed it because that interaction and purpose was fuzzy for me and the primary complaint from the group was that in
the "manage files" and "theme mapper" they wanted less not more. They wanted more screen real estate to work with the important parts and less clutter. I think more work could be done on thinking about ways to solve that issue for both sections. I would need
to do more looking around at apps for some solutions. Could you clarify for me what the core need that html preview serves? Folks from the group said they preferred to have just a second browser window open to preview, rather than have to scroll.</div>
</div></blockquote><div><br></div><div>Right. Maybe we need to optimise for second browser window, i.e. we just have a preview link that opens a new window/tab? Jon Stahl suggested the same thing.</div><div><br></div><div>
I personally think it's quite hard to build HTML and rules without cross-checking with a preview quite frequently. I also quite like the idea that when I save the rules (in the mapper) I see the changes right away (the iframe reloads automatically and shows changes). But maybe that's a power user thing, I don't know.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="font-size:14px;font-family:Calibri,sans-serif;word-wrap:break-word"><div class="im"><span>
<div> - In the theme mapper wireframes, where does the rules editor go?</div>
</span>
<div><br>
</div>
</div><div>Ah right do you mean the "overlay wizard" that you currently have that launches with click of "new rule" or do you mean the rules.xml window at the bottom that in your wireframes you had spanning across the page under the 2 windows (html mockup and unthemed
content)? In either case, I left them "as is" in your wireframe and current app (as described above) -- they seemed to work fine and I didn't have a better solution to offer.</div></div></blockquote><div><br>
</div><div>I meant the rules.xml editor, which is now 1/2 of the mapper and would in future become 1/2 under the mockup and content panels (1/4 each).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="font-size:14px;font-family:Calibri,sans-serif;word-wrap:break-word"><div class="im">
<span>
<div> - Are you sure you'd like preview in the rules mapper to be an explicit action (preview button)? Personally I'd prefer it in a panel underneath the rules file editor (as on the file manager), or possibly as something to open in a new window/tab. Otherwise,
it's always two clicks: edit the rules file, then click preview, close the preview, then edit again. Right now, it syncs the preview with the content you're viewing in the 'unthemed content' pane and reloads the preview automatically on save, which seems more
efficient to me.</div>
</span>
<div><br>
</div>
</div><div>I think this could shaped by the fact that my installation isn't working 100% on my end. I'm having trouble with that window the interaction for me has been that it isn't instant I have to click refresh to get the updates so in that case I prefer
to have it be a button I click and launch a new window than have it take up more screen.</div></div></blockquote><div><br></div><div>It's probably just buggy still :)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="font-size:14px;font-family:Calibri,sans-serif;word-wrap:break-word"><div> But this may change if these issues get resolved and I'm getting that seemless sync you are experiencing? I know that another user was complaining to me that her install
has ajax bugs causing the need to hard-refresh often, so this may be a quirk I'm experiencing. Not sure where it's stemming from though
</div></div></blockquote><div><br></div><div>Again, probably just bugs. I'll need to take a look.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="font-size:14px;font-family:Calibri,sans-serif;word-wrap:break-word">
<div>I am thinking though, that preferences will vary between those who have a higher need for efficiency and those who want less clutter in the interface I'm wondering if there is another solution to meet both camps? My hunch is that even with seamless sync
I'm probably one of those people who prefers "minimal" interfaces over "powerful" ones -- especially when I'm learning something new to me. Again I think you're gonna get these poles with these sort of preferences
</div>
</div></blockquote><div><br></div><div>I did wonder if maybe we have a consistent mechanism for preview in both file manager and mapper that is basically a preview pane that you can roll up or down (probably starting rolled up). So, you click "preview" and it opens a panel under the rules editor with an iframe preview, but you can hide it again by rolling that panel back up.</div>
<div><br></div><div>Too fiddly?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="font-size:14px;font-family:Calibri,sans-serif;word-wrap:break-word">
<div>One person suggested that all the windows be collapsible by the user. Another suggested that the user be able to decide which windows are primary and the ability to re-arrange and move/resize panes to their liking. Perhaps a little more work can go into
thinking how to solve this issue if you have the time in your timeline, I can look around for some examples this week to see if we can come up with more ideas. </div></div></blockquote><div><br></div><div>Individual resizing is quite hard to do well in that layout. Right now, the halfway house is the fullscreen option (also important to be able to test responsive designs, as Denys pointed out). I'm inclined to think we should find one layout and stick to it, rather than make it too flexible, which could get confusing.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="font-size:14px;font-family:Calibri,sans-serif;word-wrap:break-word">
<div>Again, I think I need a better idea of what your hard dev constraints are to propose recs that are feasible.</div></div></blockquote><div><br></div><div>The main constraint is time. The second constraint is that I'm not all that good at the creative treatment or the graphics/CSS to make it all look tight. Quite a lot of the proposed changes are relatively simple, though, so I think we can get pretty close.</div>
<div><br></div><div>Martin</div></div>