Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 23 days ago.
Improve this question
I store the timezone in the database upon login determined by the users IP address. This works great. The problem is:
Let's say someone logs in with remember me on, and they are in America/Los_Angeles. But then they happen to travel to somewhere else and they're still logged in... The timezone won't update unless they log out and back in
So my question is... What would be best?
Option A: Each request, update timezone in database
Option B: Ask for Timezone on registration (autofill based on IP), and then let the user change their timezone in user settings
Option C: check timezone with every request and if it doesn't match, show a message asking if they want to update their timezone to their current one
The question seems to be concerned more with UserExperience, rather than Laravel implementation.
All the options you mentioned are valid.
Normally for things like this you'd want to consult your users with it, it makes for a better experience, as well as respects the user's right to choose.
I'd recommend option B or C, since they give the user the option. (Useful for cases where someone is using VPN for example, where the timezone can change frequently, but the user wants to work on his own prefered timezone).
But remember, this is more of a preference answer rather than a standard answer.
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 4 years ago.
Improve this question
All,
I'm interested in the ability to retrieve a specific element within a FHIR resource using a single URL call. For example, suppose I'm interested in the gender of my patients. I would read the using the URL, without having to walk the XML node path every time. Right now, this functionality does not appear to exist. What do you think about the usefulness of this? Would like to get a sense of the community interest. Thanks.
-Jeff
For the default query mechanism, you can't bring anything back other than the full resource. (And don't even have a guarantee that the desired element will be present on all instances of the resource unless that element was part of your search criteria - in which case, why bother asking? :>). There's a new mechanism for defining custom queries. Refer to _query in the search/query section of the FHIR spec. However, it's not clear whether this will allow retrieval of anything other than full resource instances either.
This functionality does not exist at this time. It's on the wishlist, and we're trying to decide whether we can frame it in a sensible and safe fashion. The case you describe is relatively obvious, but many others aren't. And, in fact, when I think about it, it's not really clear to me how it works. what do you get back? just the gender element? so the server needs to - in effect - do the node walk for you, and you get, instead, to deal with a profusion of different schemas. It's not really obvious to me that this is a net saving for the client, and it's certainly a greater cost for the server.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
The software we are designing allows students to register and participate in different training courses.
When the user logs into the system they get a list of courses they have registered for. They click on the course and then they are redirected to the specific course content.
My question is, what is the best practice upon login if the student is only currently registered for a single course?
Option 1: Just list the single course, but still require the user to click on it before redirecting. Same behavior as if there were multiple courses to select?
Option 2: Upon login, immediately re-direct the user to the specific course content. Save them from having to do the extra click of selecting the course.
Option 3: Open to suggestions...
EDIT: There are no other options available on this page. They register/pay for the courses elsewhere.
Are there any other options on the course selection page other than selecting a course (like registering for another course)? If not, then take them directly to their single course (Option 2). If there are other options, take them to the list and require them to select their course (Option 1).
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
So i have a number of methods i use to minimise load time when restoring a Windows Phone 7 application when it has been tombstoned and completely closed, and a user hits the back button or (in mango) navigates to your app from the multi-tasking switcher.
What methods do you use to make sure that the user doesn't see the "Resuming..." text for a second or two?
With Mango your application will be kept in memory until the device is running low in memory. So when the user comes back you can test it in the Application_Activated method:
if (!e.IsApplicationInstancePreserved)
{ //here your code to initilize database etc.
}else{
// nothing to do !
}
You should read this page on the Execution model of Mango: http://msdn.microsoft.com/en-us/library/ff817008(v=VS.92).aspx
In any case in the application_desactived method you should save all the data because you are not sure to be kept in memory until the user comes back.
For the resuming message (and it's also valid for the startup), you should be fast as you can to display the first page to your user. Even if this first page does the heavy work (query a local database, a remote service etc...). You give to the user the impression that your application is doing something and not stuck in the splash screen.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
In a recent meeting with my client, we discovered we missed out on a Detail of User Story, that has already been implemented several iterations before.
The new requirement is not only an additional Feature but changed behaviour.
The original User Story goes like:
"Can View XYZ"
The new request however goes like:
"Can View XYZ but if B then XYZ must look like ABC"
Shall i consider this a Bug or a New User Story, or should i simply reopen the old user Story and edit it to account for the new request?
What is the "best-practice", what are pros and cons of each approach?
Well, since it is a new requirement, treat it as a new feature request. Definitely not a bug.
EDIT: Since it is not clear who missed the detail either you or the customer, you can take both ways. If you forgot about it, then it is your bug. If the customer forgot to tell about it, then it depends. If it is a little fix, you can reopen the old story. If it is much work to be done, make it a new one.
P.S. Does it really matter how you do it? The point is just implement it like the customer asks, regardless of your internal terminology.
(source: oracle-guy.com)
A Bug, a new User Story, reopening the old Story... is that really important? In any case, your customer is asking for a feature that is currently not implemented. So, as long as you can estimate its size and as long as he can prioritize it, it doesn't really matter how you call the way you capture the needs.
So, unless you have to deal with specific contractual constraints, just pick one solution, estimate the size and let the customer prioritize it (personally, I'd create a new user story).
I would edit the old story to document the modification. Otherwise you may have contradictions between the new story and the old one.
This can hardly be considered as a defect (or bug) if the customer changed its mind.
Be pragmatic: estimate it, schedule it and implement it.
I would say this should count as the old story. Your team should report reduced throughput (velocity) because of these changing requirements, especially if the original feature has not already shipped.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
What naming conventions do you use when creating work items in your task/bug tracking tools?
For example:
Do you prefix the items with an area/subject?
How do you begin scenarios/use cases? E.g., "The department manager can..."
How do you make it easier to detect duplicates?
Your project management, bug tracking and time management (if different from the pm tool) should follow the same pattern, no matter what the pattern is. I usually like to do a top down approach: project-application-page (for example: Amazon-Order Entry-Confirmation Page) - if the project/task management, bug and time management all follow the same pattern then you can track tasks to open issues to time spent easily. After the page you enter a short descriptive text of the issue. In the description area, you need to state:
environment (OS/browser)
version being tested
server environment (dev, QA, or production)
the bug (screen captures help greatly)
the expected results (what you expected to happen)
level of issue (show stopper to nice-to-have-but-will-never-get-done)