Loading Profile...
Feature requests from a new User
Hey, as a new Mockup User, my initial experience has been *very* positive. It's an amazingly productive application. That said, I've run into a few omissions I'd like to suggest for a future release.
1. I tend to "lock" items so I don't inadvertently *move* them (such as my main window). While the current lock system does just that, it prevents *selection*, and therefore any modification to said item. I see no reason that I shouldn't be able to modify the properties of a locked item (such as the title bar text of a window item). Currently, to make property modifications, I must unlock, select, modify, and relock. To me, the lock should just prevent *movement*, not selection and everything that goes with it. In order to clarify the lock status though, it might be nice if a locked item would display a small lock overlay icon when it's selected. That way, it'd be obvious why it can't be moved.
2. The "button" object supports both text and an icon, but the image is always to the left of the text. It'd be nice if the properties dialog for that object would allow the relationship of the button and text to be defined. Specifically, I'm trying to create a typical toolbar with an icon above and text below. I know there's an "Icon and text label" that'll give me that basic layout, but the the "button" look is lost.
3. Is it possible to add to the built-in icon library? If yes, I haven't figured out how. If no, that'd be a nice addition.
4. I'd like to see additional text markup supported by the tree object. Specifically, I'd like to be able to define check boxes and radio buttons at the beginning of tree nodes.
5. It'd be nice if it were possible to "set same width" or "set same height" for all objects in a selection set. I'd guess those would set the width (or height) to match that of the widest (or tallest) object in the selection set. That might fit well as 2 new functions of the "align" controls.
Well, that's probably enough for now. If any of the above is already possible and I've just missed it, a nudge in the right direction would be appreciated. Also, I hope the above isn't taken as whining, as I *really* like the product so far - I'd just like to see it continue to improve.
Thanks,
Jeff Godfrey
1. I tend to "lock" items so I don't inadvertently *move* them (such as my main window). While the current lock system does just that, it prevents *selection*, and therefore any modification to said item. I see no reason that I shouldn't be able to modify the properties of a locked item (such as the title bar text of a window item). Currently, to make property modifications, I must unlock, select, modify, and relock. To me, the lock should just prevent *movement*, not selection and everything that goes with it. In order to clarify the lock status though, it might be nice if a locked item would display a small lock overlay icon when it's selected. That way, it'd be obvious why it can't be moved.
2. The "button" object supports both text and an icon, but the image is always to the left of the text. It'd be nice if the properties dialog for that object would allow the relationship of the button and text to be defined. Specifically, I'm trying to create a typical toolbar with an icon above and text below. I know there's an "Icon and text label" that'll give me that basic layout, but the the "button" look is lost.
3. Is it possible to add to the built-in icon library? If yes, I haven't figured out how. If no, that'd be a nice addition.
4. I'd like to see additional text markup supported by the tree object. Specifically, I'd like to be able to define check boxes and radio buttons at the beginning of tree nodes.
5. It'd be nice if it were possible to "set same width" or "set same height" for all objects in a selection set. I'd guess those would set the width (or height) to match that of the widest (or tallest) object in the selection set. That might fit well as 2 new functions of the "align" controls.
Well, that's probably enough for now. If any of the above is already possible and I've just missed it, a nudge in the right direction would be appreciated. Also, I hope the above isn't taken as whining, as I *really* like the product so far - I'd just like to see it continue to improve.
Thanks,
Jeff Godfrey
I’m happy
4
people like this idea
I like this idea!
Tell me when this idea gets some attention.
The more people who like this idea, the more it gets noticed.
The more people who like this idea, the more it gets noticed.
-
Inappropriate?Thanks Jeff, none of what you ask for is possible today and all are good points. I will add it all to our TODO list...it might take a while, but we'll get to it!
I’m thankful
-
Inappropriate?Hi, Jeff. About #1, I always design on top of a big web browser control, so I lock it all the time. For me, I want it *never* selectable because I always drag open a selection rectangle within it. So I think the solution is more subtle since you and I and probably everybody else have different needs.
#2 has a workaround where you create a button with a lot of space (e.g. "Save "). Then you put an icon in that blank space and group them together.
#3's workaround is also image import. You probably know this but I'm just saying. If you know programming, you might try making a nice-looking button manually then export it to the clipboard. Paste it somewhere and figure out how to write a little Ruby/VB.Net/whatever script that will output similar XML but with the icons/text you need.
About #5, yes I kind of agree but sometimes I try to ask myself, "am I obsessing about details too much or not?" In my opinion, a Mockups power user is somebody who can make a mockup in 5 minutes, not somebody who can reproduce a Fireworks layout :)
I’m happy
-
Inappropriate?Jason,
Yeah, I see your point. There are definitely some subtleties here than that would need to be ironed out.
In your case, I assume you generally drag out the selection rectangle on top of a locked window in order to move your objects? With my above suggestion, I'd see that working this way.
- You drag out your selection rectangle, which *would* also select the background window
- The selected window would display some sort of "lock" overlay indicating that its locked status.
- You now drag the selection to move it on the screen.
- The unlocked items in the selection move, just as you'd expect. The background window does not move, as it's been locked (as the overlay indicates).
So, the question is, would the fact the window was *selected*, but didn't move cause you problems?
I guess if you were doing the same selection as above, but for reasons other than moving (such as property modification), things could get dicey. That is, if you didn't want to change said properties in the background window.
One other thought, though I'm not convinced I like it. What about 2 lock types? A "full lock" that works just as the current lock does (prevents *everything*), and a "movement lock" that just prevents inadvertent object movement?
I don't know - just thinking out loud.
Jeff1 Comment
Add a comment
This is one of the best points
-
Well the rectangle semantics now (I think it's borrowed from Photoshop, Illustrator, etc.) is that you only get what you completely surround. That makes it easy to avoid selecting nearby elements. I've been thinking about two kinds of locks too, but there's always the balance of making the app harder to understand :/ -
Inappropriate?> Well the rectangle semantics now (I think it's borrowed from Photoshop, Illustrator, etc.) is that you only get what you completely surround
I thought about that too, but that's only true if your selection starts *off* of an unlocked object. Hmmm... Looking again, I guess a rectangle selection *has* to start off of an unlocked object or you only get that object selected anyway.
> I've been thinking about two kinds of locks too, but there's always the balance of making the app harder to understand
Yeah, my thoughts exactly. It would (somewhat) complicate the use of the locking mechanism, which likely makes it a bad idea.
Jeff
EMPLOYEE
