From a design and usability perspective is it best that an edit page mimics the layout of the view page?
Our view page is very dense. The data is tightly packed together, but when editing there are going to be extra controls next to each entry field. If we leave the layout the same it will be overly crowded. Will this cause problems with usability if the fields are rearranged?
It definitely impairs usability. Two hazards of re-arranging fields are:
Confusing users about which field they are editing
Making it difficult for users to find the field they want to edit.
These problems are exacerbated on high-density pages.
There are some times when this is ok. The best example I can think of is where the editor and viewer are different users. Another (more ambiguous) case is a situation where the edit screen needs to be highly optimized for fast throughput.
If possible, you might consider splitting the screen up, or making collapsable regions to give the user (and the screen) a little room to breathe.
In general you want to keep the edit page as simillar as possible to the view page. In general. There are cases where this just doesn't make sense especially if you have to input a lot of extra data that is not shown in the view, which it sounds like is your case.
What I would try and do is make sure you continue to group and order the fields in the same manner as if you were viewing so while they might be in slightly different places at least they would be logically grouped the same.
It depends upon your workflow.
If the user has to go back and forth between edit and view, it will be very confusing to the person, as fields may jump around, they might lose which field they are on, etc.
If your view page is very dense, you might try breaking it up into sections, each with its own edit function. You could have it shoot to its own edit page or be all 'web 2.0' and throw up a lightbox with the section edit form over the view page.
The more that things are similar, typically, the easier it is for a user to use. I don't know what your particular layout looks like but from a general point of view, a crowded view is often hard to look at and cluttering it up with additional controls would make it worse.
As much as I'm not a spreadsheet guy, editing in Excel or similar products is easy because it doesn't clog up the view with lots of controls. The edit panel is the view panel. For my own products, when things are consistent, the users are generally less confused.
I have had a similar problem. What I did was have a View page that lets you see everything, but you need to drill into individual edit pages for logical sections. Within the logical sections the fields are always in the same order (and with the same labels) as on the view page. It's things like this which make your application just feel a bit nicer.
Don't throw everything onto a massive edit page just because they all relate to the same thing in your database model. Break them out into sets that make sense each with 3-7 fields on them.
If they really need to edit everything (like when creating a new thing) then I would go for a wizard approach which steps through through, presents a view-only summary and then lets them save.
Related
We have a company 'letterhead' template with all company info in a left column/sidebar. I'd like to lock that section for editing, but still retain the option to edit and/or mail merge the rest of the document as normal. I've tried the Restrict Editing feature, but that seems like the opposite function of what I need; I'd like to specify a section that is not editable, as opposed to a section that is.
The main problem is that the mailmerge/add-envelope function is disabled when Restrict Editing is on, but also adding a section break to a second page (to change to a single-column format on subsequent pages) isn't allowed either.
I've considered just creating an image of the left sidebar, but that seems hacky. Does anyone have any other suggestions on this one?
Much appreciated
--michael~
I opted for a combo of ideas, and used your [Cindy] last suggestion to bury an image in the first-page header. The table/content control seemed too complicated. Yes, it's a hacky solution, but with the wrapping options to prevent text over the image, it's like a margin without having to set them, so I can get rid of the multi-column and Restrict Editing thing, and subsequent pages are completely normal without extra section break necessary. I appreciate the responses. Thanks!
I have a continuous forms in Microsoft Access 2013 with button next to each record that will allow the user to open a link to the document.
It looks like this:
http://i.imgur.com/4CrU0i1.png
Design view looks like this:
http://i.imgur.com/sjgwZ9s.png
It works great exactly as I want. My question is "Is this bad practice?"
This form could possibly have thousands of records. Is drawing that many buttons potentially a problem?
I don't think there is any issue with adding that number of controls. But that is a lot to show the user. At some point looking though all those would be inconvenient. Maybe you can give them some sort of filter that would narrow down what is presented to them.
So basically I have made a storyboard based app which consists of table views and text. It is designed to help new programmers like a handbook. You have a table view which allows you to choose a language, a table view which allows you to choose a section (eg initialisation) a table view to choose a subject (e.g. integer) then a text view of how to go about this.
When it was reviewed, they said
Did not include iOS features. For example, your app was just largely
text table views. It would be appropriate to use native iOS buttons
and iOS features other than just web views, Push Notifications, or
sharing.
I feel like adding these things would degrade from the simplicity and educational purpose of the app. Also, I feel it might be more difficult to navigate if its all iOS button based. Also it might be more difficult to add things later.
So how would you go about adding these things to a table based app so that it can pass the review? I just don't know what they want me to add/change. I have just added a title page with a background image and iOS buttons that direct to the main section a small section and the contact us page. What else can I do?
how would you go about adding these things to a table based app
I'd start by trying to forget about what I'd already done (since that was rejected) and ask myself: how can I design this using the tools available so that the user can quickly get to the information they need?
UIPickerView comes to mind. Instead of going through three screens just to say what you want, a picker with three sections would let you select all three parameters at once.
It'd be nice if you could provide access to the information in the app several ways. What if I want to browse through all the topics? Do I have to choose one section at a to,e, or can I just start reading? A search feature would be nice, so I can find stuff even when I don't know what section it's in. A tab bar and search field would be useful for these.
Perhaps the most important thing is that however it's designed, your app should look polished. It should look like you spent time making it useful and beautiful. Give it some personality.
Is there a Tree control available for the iphone?
I need to represent a tree with sub nodes in a tree, how can I do it?
Thanks
No tree widget by default. It's basically not there because you shouldn't really need one and most cases it should probably be avoided.
A table navigation controller is the most common way to navigate down nodes in a hierarchy/tree usually.
It's hard to fit a tree like control we have on our desktops in the touch world where you have huge fingers (so huge nodes) and with the nodes offset to show depth, there isn't much space left over. Adding it to the iOS environment would create a weird UX flow so I would probably rethink my design flow if I think I need one.
If you need to fake it, you can use a table view and offset the left side of each subitem with some padding to show depth.
See this help
Rolling your own iPhone treeview control
part 1 : http://dotnet.kapenilattex.com/?p=566, part 2 and part 3 are in the pages : 585 and 633
part 4 : http://dotnet.kapenilattex.com/?p=648&cpage=1#comment-59842
I would use a UITableView and expand and collapse items further down the tree. You can set an indentation level for each UITableViewCell as it is displayed, depending on its position in the tree. You would need to keep track of which items in the tree are expanded/visible in order to always provide the tree with the correct data.
I just did just that for a project. Unfortunately I am not at liberty to share the full code. But it should not be terribly hard to write.
Let us know if you find an out-of-the-box solution.
From what I see, the best solution for my problem will be a BreadCrumbs control. I am looking for a ready solution of breadcrumbs, but if there isn't, it is not a big deal to write it.
OK, I did it.
I added a WebView and I am adding to it the crumb list. The design is similar to the Apple's official site.
When a user clikcs on the link, I call the popToViewController function and I am there.
This prevent the user from clicking Back and Back.
Hope this will help somebody.
I'm implementing a document viewer with highlighting/annotation capabilities for a custom document format on iPad. The documents are kind of long (100 to 200 pages, if printed on paper) and I've had a hard time finding the right approach. Here are the requirments:
1) Basic rich-text styling: control of left/right margins. Control of font name, size, foreground/background color, and line spacing. Bold, italics, underline, etc.
2) Selection and highlighting of arbitrary text regions (not limited to paragraph boundaries, like in Safari/UIWebView).
3) Customization of the Cut/Copy/Paste popup (UIMenuController) This is one of the essential requirements of the app.
My first implementation was based on UIWebView. I just rendered the document as HTML with CSS for text styling. But I couldn't get the kind of text selection behavior I wanted (across paragraph boundaries) and the UIMenuController can't be customized from within UIWebView.
So I started working on a javascript approach, faking the device text-selection behavior using JQuery to trap touch events and dynamically modifying the DOM to change the background color of selected regions of text. I built a fake UIMenuController control as a hidden DIV, positioning it and unhiding it whenever there was an active selection region.
Not too shabby.
The main problem is that it's SLOOOOOOOW. Scrolling through the document is nice and quick, but dynamically changing the DOM is not very snappy. Plus, I couldn't figure out how to recreate the magnifier loupe, so my fake text-selection GUI doesn't look quite the same as the native implementation. Also, I haven't yet implemented the communication bridge between the javascript layer and the objective-c layer (where the rest of the app lives), but it was shaping up to be a huge hassle.
So I've been looking at CoreText, but there are precious few examples on the web. I spent a little time with this simple little demo:
http://github.com/jonasschnelli/I7CoreTextExample/
It shows how to use CoreText to draw an NSAttributedText string into a UIView. But it has its own problems: It doesn't implement text-selection behavior, and it doesn't present a UIMenuController, so I don't have any idea how to make that happen. And, more importantly, it tries to draw the entire document all at once, with significant performance degradations for long documents. My documents can have thousands of paragraphs, and less than 1% of the document is ever on screen at a time.
On the plus side, these documents already contain precise formatting information. I know the exact page-position of every line of text, so I don't need a layout engine.
Does anyone know how to implement this sort of view using CoreText? I understand that a full-fledged implementation is overkill for a question like this, but I'm looking for a good CoreText example with a few basic requirements:
1) Precise layout & formatting control (using the formatting metrics and text styles I've already calculated).
2) Arbitrary selection of text.
3) Customization of the UIMenuController.
4) Efficient recycling of resources for off-screen objects.
I'd be happy to implement my own recycling when text elements scroll off-screen, but wouldn't that require re-implementing UIScrollView?
I'm brand-new to iPhone development, and still getting used to Objective-C, but I've been working in other languages (Java, C#, flex/actionscript, etc) for more than ten years, so I feel confident in my ability to get the work done, if only I had a better feel for the iPhone SDK and the common coding patterns for stuff like this. Is it just me, or does the SDK documentation really suck?
Anyhow, thanks for your help!
Does your document have any semantic components other than each paragraph? If you already have some concept of sections or pages, I would recommend you render each one of those as an independent tablecell. It's pretty simple to create a tablecell that makes you forget you're actually looking at a UITableView. All you would need to do is override drawRect: and setSelected: and setHighlighted: and tah dah! No More cell dividers unless you want them. Furthermore you could do some nifty things by using a tableview as your base. If you defined sections in the UITableView then you could have a nifty header that scrolls along as you're paging through your document. Another thing you could do is add a "jump to section" bar / a bookmarks menu, and that way you don't have to provide selection across the boundaries of sections.
Massive copy paste blocks would be pretty painful on the system as well. Further, if you went through the trouble to provide this content you might not want to make it too easy for someone to copy it all at once... (Can't follow this line of thought more without more specifics on your project).
If you really do want to provide the copy paste options you could add buttons to each logical page or section that immediately selects and copies the whole section for the user's convenience. (Maybe with citation associated?)
I recommend you lookup the UITableViewCell UITableViewDelegate and UITableViewDataSource in the SDK docs as those pages will significantly help if you choose to use this suggestion.
Just two random observations:
Can you afford to create a paging interface? (As opposed to “endless scrolling”.) It looks like a paging interface would be a lot easier on system resources.
The UIActionBar is actually the UIMenuController class. The interface is a bit weird, as the menu is a singleton (wtf?), but I’m sure you’ll have no trouble figuring it out.
Hope that helps.
Here's a potential solution, but I don't know if it's crazy. Since I'm still so new to iPhone development, this might be a big no-no.
Anyhow, I had the idea to render each paragraph of the document (whose dimensions I've already precisely calculated) as a cell in a UITableView. Since UITableView already has mechanisms for cell recycling, I wouldn't have to implement that from scratch, and the document could be arbitrarily long without causing resource consumption problems.
Of course, I'd want to get rid of the line separators between cells, since I want the UI to look like a document instead of a table.
Or maybe I could render each page of the document (like a typical PDF, this is a paged-document format) as a table cell, and override the cell-separator graphic to look like a page boundary...
But would it be possible to get rid of the default touch behavior within the table, and instead implement text-selection on the table cell contents? Would it be completely impossible to implement text selection that crosses paragraph boundaries (between multiple table cells)?
The UIWebView is a good choise, but we need another application to pre render the pages percisely using each font and each style sheet and store the rendring information into a database table:
chapter_id int primary key,
startlocation int,
end location int,
fontsize int (or stylesheetname string)
Using JavaScript we can calculate how many words fit in a div with out scrolling.
UIWebView is good as it provide rich content and it has selection and highlighting behavior.
Hope this helps.