Talk:Interface mockups

- where can the 'About' and 'Help' buttons go? - Vadim

- Vadi, I've made a second set of mockups that solve the problem. Please check them out.--Frandavid100 07:33, 30 May 2009 (UTC) - Wonderful. It's starting to be quite convincing now.

I gave the overall software a lot more thought, and started a Personas page which should help some. Also, GiftWrap will need a plugin system (launchpad should be optional, and there are so many different build systems out there is not even funny). So that will need a plugin management window somewhere - preferable a tab in Preferences. So, a Preferences button somewhere is needed. Vadi 17:45, 30 May 2009 (UTC)

- Vadi, I've been thinking for a while about where to put that preferences button and it would be quite hard to do without cluttering and overcomplicating the UI. There is so much stuff. Would the obvious solution, using a toolbar or even a menubar, be acceptable?

- That's what I'm getting at. A toolbar would be okay, but then wouldn't it make more sense to move into the first window, which has more space for other items too? I'm afraid we'll outgrow this mini-app style dialog. What do you say?

Btw, forgot to link to the Personas page. Vadi 18:16, 30 May 2009 (UTC)

-Well, I agree that the mockups are limited... but I still think that the multi-window approach is a bit over the kill. I've made a third set of mockups, with a toolbar and a menubar. These are much cleaner than the previous and allow to easily going back and forth between the fields tab and the progress report. By switching to the "progress" tab automatically when the "generate" button is pressed, you manage to only need one window for the whole process.

Also, the "save" button lets you save your project.

- Excellent. I think this goes quite well then, for now I don't see anything wrong and I like that it's one window. Very well done. If you did it in Glade, can you create a branch on https://code.launchpad.net/giftwrap please? Vadi 19:44, 30 May 2009 (UTC)

- I'm afraid I can't use Glade for the life of me, I just gimped up the whole thing. Sorry mate. --Frandavid100 20:43, 30 May 2009 (UTC)

- I'm impressed by your skill, then. No problem, we'll do it. Vadi 13:28, 31 May 2009 (UTC)

- What would the 'Archivo' menu contain, if you had anything in mind? Vadi 13:29, 31 May 2009 (UTC)

- That was actually just filler, I had nothing in mind. But I guess there should be a file menu with new project, open, recent files /projects, save project. Then an edit menu with preferences, plugins. A Tools menu with generate, upload to launchpad, install. And a help menu with index, about. Am I leaving something out?--Frandavid100 13:43, 31 May 2009 (UTC)

- It's all good, just wanted to know if you had something planned. Vadi 14:04, 31 May 2009 (UTC)

- Yep that's wonderful. I suppose we'll have a 'Generate' button at first, and if something is already in the queue, then change it to 'Add to Queue'.

- I think the HIG discourages the use of buttons that change: they're supposed to confuse users. Instead of that, we could just place both buttons next to each others, disable "add to queue" for the first file and "generate" for the second on.

We could also remove the "upload to ppa" and "install" buttons from the toolbar, too, since they don't really make sense in a multi-project interface: what do we want to upload? The file that has been generated, or the one we're about to generate? Instead of that we can place both buttons in the queue list, one pair for each project, and spawn a message when everything's completed, with "upload everything" and "install everything".--Frandavid100 18:36, 4 June 2009 (UTC)

- We don't be changing buttons - they'll still be doing the same action. Just the labels are more appropriate.

This change is rather intrusive to people who just build one package at a time, and most of our users will be doing just that. So I think that we should do a separation of the single and multi- interfaces somehow. But I'm not sure how, as the 'install' button suddenly disappearing would actually be intrusive.

- About the "Generate" and "Add to queue"... how about just having "Generate", and have it add items to the queue when pressed? Also, turn to the Queue tab and select the newly added project. That way we wouldn't have to change the label, and the user would immediately see where his project has gone.

We could also move Upload and Install to the queue tab, but available at any moment. I'll do a mockup right away.

- Alright, take your time on this. The queue thing will take a while to come, it was just something I wrote down that we keep in consideration while coding (so we keep it so that it'll be easy to add a queue in the future). Vadi 23:16, 4 June 2009 (UTC)

- Sometimes we'll need to display a progress bar while not yet building a package (for example, scanning a large archive for a file listing). How do you propose we display that? I was thinking of a label + progress bar in the status bar. Vadi 00:58, 6 June 2009 (UTC)

-I reckon that would be the right way to go, yes (BTW, I posted a mockup for my last suggestion, but I'm not so sure about that one myself now).

- I've been thinking over things as we'll start on planning the core of the program tomorrow. I realized that so far, binary-only builds (where we don't compile but just make a .deb that copies a bunch of files somewhere) aren't accounted for. Not are really theme packages. Both require selecting a bunch of files and selecting where each goes (sort of like the Target Mode of http://en.wikipedia.org/wiki/Debian_Package_Maker - the 2nd graphical packaging program but dead too). I don't see a place for this currently, so a new tab is the way to go.

Also, need to stuff in a ".desktop editor" somewhere. If one already exists in the sources, we'll just read info and fill in the fields, if no, we'll have to create one. It shouldn't be too big, I reckon it'll take up half of the current height we got.

One challenge would not to make this seem too complicated when for the bare minimum, as you saw by the 0.1 video, you don't need to do a whole lot. Vadi 02:59, 7 June 2009 (UTC)

-Sorry for the late reply. It's been a hell of a week! How many fields would actually be necessary for this? Could we place it in the "Optional" tab somehow?

- Oops. The field to open the source archive/folder with was forgotten in the version 2 Vadi 10:34, 8 June 2009 (UTC)

- How should the 'project' management be done? ie opening a new project? I don't think we should go by explicit locations, we can just abstract that away so the user is presented with a list of projects they already got. Maybe have 'open' open up a small window with an icon view ala default nautilus?

-The "Open" button could have one of those arrows pointing down, that offers a list of recent projects. Also a "recent files" entry in the File menu, containing recent projects and archives.

As long as Giftwrap doesn't support queuing, I don't see a reason to add a "new project" button. Simply opening an archive should discard your current project and start a new one.

~ 'Recent projects' thing is a good one, added. But how to deal with opening a new project though? We don't have an exact location on the disk for them, so I think an 'open project' window that lists all projects that you have is necessary. Recent projects won't always have the full list.

-I'm not sure I'm following you. What do you mean, that there won't be an exact location for projects? I supposed projects would be saved as simple files? Something like "Project1.gfw"?

- Yeah, thinking about it, nevermind that part ;)

- Question - how should improper fields be handled? Atm, I added such that when keyboard focus leaves a field, and it's invalid it'll turn a bit red. When the user is typing, and as soon as the field is valid again, it's reset to normal.

So that tells the user a "yes/no" as to whenever the field is OK, but does not say "why". What is your idea on filling this? Either have a small font text show up under the field explaining, in a yellow box on top or below, or a popup? or something else?

-I think the easiest thing to do would be to do the right field thing, and specify what exactly is wrong in the status bar. There's no place for text over / under the fields, I feel the yellow box should be used only exceptionally, and I think you wanted as few popups as possible right?

I think the program should fill as many fields as possible automatically, even the synopsis and description if it's possible to retrieve that data from gnomefiles. If ALL obligatory data is filled automatically, the focus should go automatically to the generate button.

If there is one or several fields to be filled obligatory, everything should be greyed out but the first field. When it is, the second field should become available, and so on. When every required field has been filled, everything (all other fields, the generate button) should become available, and the focus should go to the generate button.

The idea is to hold the user's hand as much as possible, and not let them any mistakes. I'm thinking about my mom trying to build a deb here, and how to keep her from messing anything up. So first get her to edit what is ABSOLUTELY NECESSARY and nothing else, then let her edit everything else or go directly to build the file (which she should).

- Yes, of course we plan on filling in as much of information as possible. Saying the problem in the status bar makes sense too, along with the widget disabling for the most part. I think it would hurt to actually force an order on the way they are filled in though, perhaps going 'level-wise' - don't allow optional fields to be filled in until general ones + don't allow the user to click on the generate button.

How about that? Though error messages in status bar is... hm. I hope they'll be noticable enough, because I never look at the thing. Vadi 12:22, 13 June 2009 (UTC)

- Well, my main reason for proposing it is that it would make it easier to understand the status bar's messages. I mean, if the status bar is asking you to take a certain action and there's only one field available you can't get lost right? On the other hand, if you have four or five you'll be more likely to misunderstand the message and mess something up. What kind of problems do you think it would bring exactly?

Another option would be to change the status bar message depending on which field has the focus. That, combined to the red background for fields with errors, should do the trick.

- The focus idea is good one, as it'll help solve the common of multiple problems at once. Thanks, I'll give it a go. Vadi 13:10, 13 June 2009 (UTC)