| Author | Message | ||
     Cun Liu |
I have a scenario that a quick view functionality is implemented to help user viewing information of instance of entities without requiring scrolling the table horizontally (here, that table lists result of query on entities). the quick view fields and labels can be different from screens (different query on different entities). In this situation, do we count one EQ for all quick view or each quick view with different fields one EQ? Or we may even do not need to count the quick view functionality? | ||
| Abinash Sahoo |
Hi Cun, I didn't quite get the part when you say "without requiring scrolling the table horizontally". What I understand from your explanation is that you have a need to implement some sort of "PREVIEW" of instances of different entities. The user probably expects , with a click of a button she would get the brief view of the entities in each cell of a table. If my understaning is correct, then it would be a single EQ. No matter, you might have to write multiple select queries in the back end for each entity, but it would be part of a single user requirement. | ||
| Maxim Rusakov |
Hi, rephrasing your question: should 'quick view' be counted as a (1) single EP or as (2) several EPs or no (3) EPs at all. I think it is (3). I would count "ordinary view" and "quick view" as one EP "View". To count complexity of "View" I would combine DETs and FTRs for both option of viewing an entity. | ||
| Steve Neuendorf |
Hello Cun, Abinash and Maxim, It is a little confusing, but it sounds as if when you execute the inquiry, you are presented with a single screen with navigation links to the balance of the inquiry results. So the process would be something like 1) call list; 2) view list; 3) call detail; 4) view detail. Most likely you can call the list back to view additional detail, and maybe even you can drill down from the detail to view lower levels of detail and bounce back and forth among the levels. The key is none of these steps are self contained. Only when considered together do they pass that EP test. So you would look at all of the steps together to identify the DET and FTR and PL involved to classify and rate the function, and to apply the uniqueness test as appropriate. So Abinash's understanding is correct in there is only 1 EP, and the self contained test is why. Hope this helps, Steve | ||
| Maxim Rusakov |
Steve, (1) do you mean that "there is 1 EP" regrdless number of types of entities that can be listed, viewed e.t.c? or do you mean that "there is 1 EP" per entity type? So, if there are X ILFs than there are X EPs. (2) I assume that the application is a Web application which uses hyperlink navigations to view entities. For example, a user can navigate (view) to a specific entity from different pages. So, a user can view entity without "list them" first. Would you still count list+view as a single EP? | ||
| Steve Neuendorf |
Hello Maxim, The initial question was confusing. Say everything on the initial list is equal. That is the result of selecting any item on the list was substantially the same as selecting any other item on the list, determined by the content of the list item selected; then there is no question there is 1 EP. If there are different sections of the list that give dissimilar results, more like the list is a portal, then we would need more information, but likely there would be more than one EP. Hope this helps, Steve | ||
| Cun Liu |
Hi all, Thank you for your response and sorry that I should have a more clear description on my questions. I would clarify as following: say, there is an ILF A, with 10 DETs. A query is implemented to view a list of instances recorded in A. the list will show all the 10 DETs. However, customers cannot see all 10 DETs at the first glance as the screen is not big enough. Scrolling bar is used to scroll the screen. Then a quick view is implemented that user can see the all 10 DETs together in a popup window for a certain instance by click a button. And the quick view function is a global feature and implemented for like ILF B, C and etc.. And my question is how the count the quick view function. I hope I explained myself clearly this time. (Message edited by lcdtiger on May 19, 2010) | ||
| Charley Tichenor |
Cun Liu -- It sounds to me like you might want to consider counting the quick view as an instance of end user efficiency, General Systems Characteristics item 7. It seems that the need for the quick view is only because the main screen is not large enough -- a hardware constraint, not a data flow constraint. If this is true, then I don't see any countable function types like EQs for the quick view screen. However, if the quick view works something like a pop-up window or scrolling and it is available often then I'd consider counting it in the GSC framework. Charley (Message edited by charleytichenor on May 19, 2010) | ||
| N.Venkateswaran Username: Nvenk Post Number: 264 Registered: 07-2009 |
Maxim, if there are more than one ways to achieve the same functionality, we have to count only one Ep irrespective of the no of ways to achieve the same result. Hope this answers your question |
