I guess this is less a direct problem but more of an implementation question.
For drag and drop interfaces. How do people store the order of the elements that are being re-arranged. Since a user expects the order to be preserved when the user refreshes the page, how do you store that kinda information in a relational database or other persistent layer?
A number system seems extraneous requiring multiple updates anytime anybody arranged anything and I couldn't think of a nicer system for storing that information especially if the user doesn't have to click "Done" or any other button after re-ordering. (IE Facebook Photos)
Any help would be appreciated.
One approach would be a linked-list style: for each element, you store what is after it (or both before and after, for a doubly linked list). This way, when you move something, you only have to update the affected elements. Since you don't typically need to retrieve, say, the 2357th element (more typically you need to recreate the entire list) the performance impact should be fine.
Related
When programming i usually do everything myself and recycle code when needed so for once i decided to try out a development platform to speed up the process so i picked oracle apex- only to find myself suffering with overchoice
Normally if wanted the user to give me some data id just make a form and the data just ends up on my database, not hard.
this isnt what i want to make, this is just for the sake of an example of the way one usually goes about this
another example
But now in oracle apex i dont even know if this is even the right way of asking end user to input data into a table, what should i do if -for example- i just want to make the user run some calculations and then store the results? Is there something specific that apex already has for this or do i do it myself normally
Any tutorials or the names of the functions i need to use would be helpful
I think maybe what you might want is Report with Form.
Its a setup the Page Wizard can make for you which is essentially exactly what you want. You select the table and columns, then it makes one page with a table of all entries, and you can click on an entry or click to make a new entry, and it opens up a form with the relevant page items which you input or edit, and then save.
Maybe a general APEX guide would be best for you since you are so new to it. Because if you know what is possible, then you might find different solutions to problems you have. I dont have a guide to recommend unfortunatelly, but I am sure you can find plenty on google, just make sure the version is correct, it doesent have to be for your exact version(there is a big difference pre 18 and post 18, less so with 19 and 20)
Yes, APEX can be a bit overwhelming in the beginning. Your question is very generic so it is hard to give you a detailed answer. In general, if you have the data in a single record, then a form is the way to go (easiest is to start with report and from). If you need to modify certain column data after user submit, you can do that in processes or computations before submit.
Feel free to ask a question with your specific business requirement - you're pretty sure to get an answer here.
If you have an experience in UX or Security, please answer this question.
I am working in some project and we need to show the object id to the user.
So all edit form's has the id, the client ask for this --".
My doubt is, what is the best way to show the id in the form?
I did this way, the ID is just a text:
But some one is showing the ID as a disable input, but this seems wrong to me.
Can some tell me the best way to show the ID ? Maybe a third option.
And please explain your answer, I need to convince my team.
Thank's!!!!
An Information Architect here.
I think your first inclination: putting the ID in the visible field as text, is correct - provided the text is selectable.
Do not put text that can't be edited into what looks like an editable field, even if it looks disabled. You're telling the user "you can do SOMETHING to edit this number, but you're not doing it now, and I'm not telling you what you have to do, nor why you'd want to do it, nor what happens if you do". That'd be a really poor approach.
One other thing to think about: does it need to be the first thing in the form? Sure, the ID is probably the first field in the database, but it's probably not of first importance to the user. Order it so it makes sense to her.
Information in the page has a hierarchy, and the top and left of that hierarchy (in languages which read left-to-right) is where the most important thing the user needs to see should live.
(That doesn't mean you can't have a header with a top-left logo or top navigation on the page - of course you can. People understand what that stuff is - we're talking about the top-left of the content area).
If you need more background on information hierarchy, I suggest you search for information on "F-pattern reading" for a quick visual example of how people consume information in the page. The Poynter institute did, I think, the original research on this with an eye-tracking study.
You only show object id and name in the page. If that's all that's there, the page's simplicity means you don't need to think it much further through.
If there's more, you'll need to order the information in a way that's important to your user, and that's natural for completion (for example, an Address has many common components, and completion should occur in the order a user would write the address in the context of the local language).
To understand how well you've done with the page's usability, take your best shot, mock it up, then show it to a few (non-technical, non-project-manager) people. Hand them a pencil, and say "use the pencil as your mouse. Point and click on things to do [name of your task]. Don't tell people how to do it. Just ask them to point at things on a printout. This is called a paper prototype, and can be an inexpensive way to learn a lot about your design. Try this with maybe 5 people before you refine and start to code it up.
I'm not sure what the "Security" aspect is (is it a security product, or an IDM component?). If the question is "Can I show the user the object ID?", you'll have to answer that in the context of your internal security model. You'll need to estimate what you're protecting when the object ID is not shown, what's at risk when it is.
Ideally, your system would prevent a malicious user who knows the object ID from doing anything with the known information, and from harvesting object IDs in bulk.
Of course the correct solution is not to show the ID of an object. IDs (along with object) are internal technical terminology, the user does not care that you use an id to uniquely refer to an object in a database.
Just remove the ID field entirely.
I have very big form, it could have maximum ~1000 elements. It has many embedded forms which has another embedded forms, obviously they are collapsed by default.
My form has some entry points from which user can start, most of controls are not required, form is splitted into parts. Each subform can be folded to summary box.
I think that workflow with that type of form is ok. User can open it and in one page he can make many types of changes in data and in most cases those actions aren't connected each other.
Are there any design references, researches about such big one page forms design? Maybe some standards about designing UI with input controls pattern?
You need to provide a workflow. A form that big on a single page will confuse people and lead to people not even bothering to fill it in.
Break it into smaller forms, and provide a wizard-style navigation process to move from one page to the next as the user fills in parts of the form.
Even then, 1000 data points is a lot for a single form, and a lot to ask people to fill in during a single session. So you would be well advised to allow people to leave the form partially filled in, and return to complete it later, without having to re-do what they've already entered. Some sort of session save facility is required.
I have a project I've been working on recently using MongoDB. Basically, the core element of my website is "projects". Each project will contain a nested "strings" object, which will contain a large amount of strings... So, each project is quite massive and can approach a megabyte or more. As such, I want to have the projects in their own collection.
The problem I'm having is that I'm not for sure how to assign users to a project. Should a user contain a list of the projects they're enrolled in, or should the project contain a list of users? When should I choose one or the other? And is there a better way? (I haven't touched MongoDB in quite a while, so I'm a bit rusty)
I cannot immediately think of any serious stopping differences between the two. I suppose maintaining it user side might be easier for:
User unsubscribing from projects since you just modify that user row which will likely have only that atomic lock on it anyway, unlike the project row which multiple users could be trying to unsubscribe from at the same time. So doing it user side might make better updates and concurrency in general.
The previous point can apply to users subscribing to projects as well.
User deletions, you just delete the user row...simple
So considering these immediate things that come to mind I would probably choose to embed projects within the user.
Have a look at http://www.mongodb.org/display/DOCS/Schema+Design. The guideline that would apply in your case is
Generally, for "contains" relationships between entities, embedding should be be chosen. Use linking when not using linking would result in duplication of data.
If a user can be enrolled in multiple projects, and a project can enroll multiple users, it seems best to have separate collections for Projects and Users.
I would like to create a text based RPG game for iPhone. In this user will have some questions with answers, and navigate to the next page depends on the answer in which the user selects. As per the requirement I have to store the entire story in the app itself. And I need to access each event in the story, when the user selects. So which kind of database can I use?
Please share your ideas.
Thanks.
I'm not so sure you need to create some type of off-device database. If the game has predefined answers and questions then you should probably load the app with each of these on the device.
I'm sure there are plenty of ways to go about this, the simplest being if/else statements. This would obviously be a hindrance and easy to mess up if the storyline is long.
One thing that comes to mind would be to design the story using a Tree representation. The starting point would be the root of the tree, and from there the user would progress down the tree until it eventually reaches a leaf (end). Depending on the number of options a user has for each page, this really wouldn't be too tough to implement if you have any knowledge of this type of data structure.
But, this is just off the top of my head. I would definitely consider the use of a Tree data structure though.