Mobile Tool Integration

[bsaiken]

Prerequisites:

1. 249 - closed

2. 504 - closed

3. 437 - closed

4. 555 - closed

Tasks (to split into single issues):

1. Pre-load forms: template, task-specific, location-specific.
2. Add field task.task_notes (Issue).
3. Add subdirectory FTTool (Issue).
4. Add task.start_date field (Issue).

https://docs.google.com/document/d/1H7MGLi_Z7m8-f6B2VCpCRVj4jre_fn_OC_HBnROsw-c/edit

[FWAJL]

@bsaiken

Tasks:

1. For the document of type "form", let's prefix the document name with "fwm_type" where "type" is task, location or any other string.
2. Related to #404 to notes management
3. Related to role management

[bsaiken]

@FWAJL Item 1 is address by Issue #672.

[FWAJL]

@bsaiken

FYI, this issue will need to list the different milestones for the work once the SOW is final. No code will be committed here but everything in the appropriate milestone.

[bsaiken]

@damirius @FWAJL

Let me explain, for Damir's benefit, the needs for this Issue, Mobile Tool Integration, and how it relates to the Issue #421 and the Issue of roles. This must to be prioritized above other Issues because I need to release a SOW for preparing the Mobile Tool interface.

A bit of background first. I have a deadline of May 31 to complete certain aspects of this web tool. There are many reasons, but the most straightforward is that I have funding through the end of May. Some features, like the administrator login, are not essential before the end of May. As it is, I already have administrator access because I can log into Hurray Host and edit the database directly. Inefficient, but acceptable for now.

The PM tool, which we have been working on, is for use by Project Managers (PMs). The mobile tool is for use by Field Technicians (FTs). The way I see it, the Admin tool is for use by the Admin, but I will only discuss the mobile and pm tools here. The mobile tool interface will take some time to code, so I need to start soon. However, we must first resolve the question about how to access the mobile tool pages.

I would like the mobile tool and the pm tool to be separate. This is NOT because I need to prevent PMs from accessing the FT pages, nor do I need to prevent FTs from accessing PM pages. If a PM wanted to allow a FT to access the PM pages, they could simply give the FT their login information. Due to the relationship PMs have with FTs in my line of work, this is likely. If you look at the table task_technician, there is a field is_lead_tech. This field is not currently used, but the idea I had was that if the PM designated a FT as a "lead_tech", then one of the things they would (exclusively) be able to do is to have access to the PM pages, just like the PM. In our currently line of development, the FT could take on the PM "role" for the designated task.

So, there does not have to be this strict exclusivity between PMs and FTs. When a FT logs into the site, they could be directed to an entirely different "index" page, one that even has a completely different left menu. In fact, the way I envision the FT pages, there will not be a left menu at all. Once logged in, a FT could try to access PM pages by typing in the URL. For example, one of the pages that the FT would NOT see, is http://dev.fieldworkmanager.com/technician/showForm. However, if a FT manually typed in this URL to gain access to the page, it's no crisis - at least not at this stage of development.

All I need at this point is for the FTs to be directed to a different "index" page when they first log on. Currently, the PMs go to http://dev.fieldworkmanager.com/project/listAll. If the FTs are simply directed to a different page, this issue will be resolved - at least for now. As the FT navigates their pages, there will simply not be a link to any of the unnecessary PM pages.

The FTs, for the most part, will see views that are different than the PM pages. There are some cases where the content they see will see the same. For example, there will be a link on the FT tool to see the some of the content of the page http://dev.fieldworkmanager.com/location/listAll. This is really not accurate, what is really happening is that the FT will see a page, formatted to fit a mobile device, that includes the active_list module (line 14 of listAll.php in \views\Location).

Now that I think of it, I am not certain this will work using roles. Even though the FT is seeing the same list of Locations as the PM, the the view and the behavior of clicks associated with each item in the list is different. Here are some examples of different behaviors:

• When the PM clicks a Location, they have the ability to "demote" the Location to be an inactive Location. FTs will not be allowed to do this.
• The FTs will NOT see a page with two columns "Active Locations", and "Inactive Locations". The FT page will look something like this:

• The text for the Locations on the FT page will be dynamically color coded.
• When the PM right clicks on a Location, they get a contextual menu enabling them to "edit" the Location. The FTs will not be allowed to edit a Location.
• When a FT clicks on one of the Locations in their list, they will see an info window with menu options unique to the FT. The PM will not see this info window.

With all these behavioral differences, I don't see how we could just display the same page that the PM sees.

The idea I originally had was to generate entirely new views for the FT pages. In fact, that's why the current code is in the PMTool directory - we thought of creating a new directory, FTTool, for the FT views. The FT views would have their own controller files and we could use the existing code for the PMTool so we did not need to start from scratch.

Now, I understand there are always many ways to attack a problem like this. I am interested in hearing options. Most importantly, I need to know if it is really going to be possible to handle the disparate views and behavioral differences by using roles and, if it is, is that really easier than generating new views for the FTs.

[FWAJL]

@bsaiken @damirius

See my last comment in #421. I think it is possible to implement roles to say FT sees those X routes and PM sees Y different routes where X and Y are a different set of routes.

Reminder: a route is a controller method and a set of views. So we don't need new controllers but new controller methods and new views for each route. The behavior is controlled by the controller methods and the look&feel with the views.

I hope we are all clear on what to do and how to do it. Let me know if not.

Thank you.

[damirius]

@bsaiken @FWAJL

Adding roles to routes is still viable option. We can still create totally new controller actions for FTs. As both of you noticed, some things will be so different like location listings that just adding role attribute on module or on route will not work. Implementing all that on the same route will be a lot harder instead of just creating new routes for FTs. So as Jeremie suggested, we can just add new routes which will have role="FT" and leave old ones with role="PM", essentially instead of sharing the same routes we will create new ones.

[bsaiken]

@damirius @FWAJL Great! Let's charge ahead! I don't think you need to do much more on this Issue. Let me know when the roles are set up so that someone could start the mobile tool development. I will need to modify my SOW for the mobile tool accordingly.

[WebDevJL]

@bsaiken @damirius

We will need to clean this issue and move the comments related to roles in a backlog issue because it is not the place.

Do you agree @bsaiken?

[bsaiken]

@FWAJL Yes, I noticed last night we were commenting on the wrong Issues. I don't think we need to clean up the history, but let's keep it straight going forward and just refer to another Issue number to capture the history, if needed.

[bsaiken]

@damirius @FWAJL @gsouvik

We don't need that many pages. In the header, we could have the name of the Task (breadcrumb) that the FT is working on. If they have more than one, and they haven't decided, let's add a popup Prompt box asking them to select one - that's obviously well suited to Souvik. The FT can't work on more than one Task at once, so forcing them to select to start is fine. Of course, if there is only one Task they go straight to the map page. This takes care of Issue #874.

The menu options are: a) Edit info b) logout and we add c) communicate d) view map e) notes

Here are the only needed pages:

1) A landing page. So I suggest the Task Locations map page. This includes the map and the sidebar, so we don't need a separate Locations List page. It looks fine on my iPad mini. With the left menu shrunk, we could use that space for the sidebar list. Most of the functions we need are going to be in the info windows. This is mostly done with Damir making some minor changes (I have already created the Issue for him). So this would cover Issue #846 and #848. And #849 (see below).

2) The edit info page (from a, above). This page is already done, we just might need some CSS. This would be Issue #847.

3) The Communicate page (from c, above). This is a variation of what we have already done - so we can hand it to Damir. The FT can communicate with either the PM of any SP. This handles both parts of Issue #850.

4) Notes. This is a variation of the communication page, actually simpler. There no recipient, just store the "message". Or here's a thought - we could add "Project Notes" as a a recipient. Takes care of #849, part(4). We could also leave this out if necessary.

The only other Issue is #849, part(3), and this is a fillable pdf form, so it will be handled on the map info window. There will be a list of click-able forms for each Location in the Info Window. The only quick option I have for the form right now is to open the form with a click (Full Screen) and allow the user to fill it out. Then they can take an image of the page and attach the image to message sent to the PM. If we use the exact form title that we created with the copy forms function, we can separate out and store the completed forms.

---

I was working on the mobile site some more, and thinking about how it should look. One thing I realize is I do NOT like having glyphicons as links. There has to be some text to describe to the user what the link does. There are three common ways of doing this: 1) have a glyphicon with title or a tooltip, or 2) Use a glyphicon AND text, or 3) just use text. I noticed, in the work you have posted, you have 2). Text is necessary. On the mobile site, the user doesn't (usually) have a cursor to hover over the glyphicon. Everything has to be revealed with a click. Tooltips and titles are not useful.

I was looking at a lot of mobile sites to see how they navigate. One very common option is to (yes) have a left menu, like ours, but it is normally hidden. Clicking on the menu glyhicon opens the left menu. The menu glphicon is pretty universal, so this is an exception where a glyphicon (only - no text) is OK. The glyphion I am talking about is "glyphicon-menu-hamburger". Unfortunately, it is not in our version of bootstrap. I tried downloading the latest version of Bootstrap, but it's not that easy. We could use the menu glyphicon in the upper left corner and have it reveal and hide the left menu. I am OK with a left menu if this is how we use it.

Looking forward, contextual menus, which require a right click, are no-nos on the mobile pages. So keep that in mind.

[damirius]

@bsaiken @gsouvik

OK so first steps are always the hardest :) Take a look at feature_mobile branch. I've added mobile/map route. It should be the same as activetask/map page, just note that you can see the tasks which are not yet activated. I don't know if we want it this way or not. Also currently I'm fetching last task assigned to that FT, we should change when @gsouvik implements prompt box for task selection. I've left only 'task map', 'communications' and 'notes' in left menu and left full menu titles there like you mentioned. You'll see some ugly glyphicon in the top bar, you can press it to hide/show the menu. Keep in mind that content div stays the same width, so map and sidebar just slide left. I didn't want to loose to much time on css so I left it like that. We can work on that later. I still have to test out infowindow editing and all that stuff. It should work but I want to see what exactly can FT edit there so we can modify it if needed.

Ah yes, feature_damir is merged into dev and then merged back into feature_mobile, since last few commits on feature_damir are all related to the maps and I needed that code here too.

[bsaiken]

@damirius All I see is the left menu. That is working just the way I want. The default should be left menu hidden. Move the header functions "View and edit your details" and "logout" into the left menu and remove them from the header. The header would only show the logo, a breadcrumb with Project and Task, and the name of the Technician. We will put the menu glyphicon to the left of the logo.

None of the individual pages are showing for me.

There have been a few database table changes lately, please make sure the database tables on the live site are all up to date, and I will copy down that database to my local machine when you notify me.

[bsaiken]

@damirius Damir, Since we are going to have a left menu, then one of the options in the left menu is to show a selectable list of Tasks. So add that to our list of menu options. We don't really have an Issue specifically for the left menu since we weren't going to have one. The closest is Issue #846, so I will add a comment there so it includes the Left Menu.

[damirius]

@bsaiken

I've added edit user form for FTs on both admin dashboard and on FTs Mobile UI. feature_mobile branch

[bsaiken]

@damirius Looks good.

[WebDevJL]

@bsaiken @damirius

There might be a little check to do or a query to refine:

[bsaiken]

@damirius @FWAJL It works fine. If the FT has only one Task - it goes directly to the map page, even if they click "List Tasks", otherwise the list is displayed. At one time we were going to have a popup, but we now we don't need it. I'm not sure how you created the error.

[WebDevJL]

@bsaiken @damirius

Easy to replicate : just log in with a FT with no task assigned.

[bsaiken]

@FWAJL @damirius OK - I see the problem. Unfortunately, as we only have a few days left, we will not have time to fix this bug.