Mobile usage - responsive behaviour

[rowalth]

Are there any plans or initiatives to make ffcrm accessible via mobile device?

[steveyken]

I would dearly love to see this happen. It's just a matter of time and effort. I'm not able to put much time into FFCRM development at the moment, but welcome PRs and others getting involved.

[imkarthikk]

I've just started working on this. But the progress is going to be a little slow. I love the project so much and I want to integrate material design into it. :) Let me know what you think.

[ghost]

@steveyken @imkarthikk i started tweaking it yesterday, but got stuck at simple_forms and jumpboxes. so i'm thinking to create mobile first template in bootstrap and then making views.

[imkarthikk]

Makes sense. I can help you out with that. Lemme know.

Sent from my iPhone
Smart businesses run SHRINK. Do you?

On May 17, 2016, at 4:24 PM, Lixon Louis [email protected] wrote:

@steveyken @imkarthikk i started tweaking it yesterday, but got stuck at simple_forms and jumpboxes. so i'm thinking to create mobile first template in bootstrap and then making views.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub

[steveyken]

Encouraging to see work on this. Appreciate the effort people are
undertaking.

There's a lot of things about the architecture of FFCRM that make it hard
to skin better (not using unobtrusive javascript for example). That said,
there is a real end-user need to skin and get this working on mobile. I'd
certainly use it!

There is also another thread with panigrah on the google lists about using
AdminLTE skin which I believe is also mobile friendly.
https://groups.google.com/forum/#!topic/fat-free-crm-users/VM3NAKEQgow I'd
make the same comments on there as I am here.

Personally, I'm unable to support with work effort right now, though I'd be
open to merging pull-requests when things are ready.

I will also be taking a break until end of June so will be unresponsive on
email during that time.

I guess my vibe is this: highly supportive of your mobile efforts, low
expectation to be able to assist myself.

Regards and thanks for reaching out,

Steve

On Wed, May 18, 2016 at 1:40 AM, Karthik K [email protected] wrote:

Makes sense. I can help you out with that. Lemme know.

Sent from my iPhone
Smart businesses run SHRINK. Do you?

On May 17, 2016, at 4:24 PM, Lixon Louis [email protected]
wrote:

@steveyken @imkarthikk i started tweaking it yesterday, but got stuck at
simple_forms and jumpboxes. so i'm thinking to create mobile first template
in bootstrap and then making views.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#465 (comment)

[rocknrollMarc]

Yap I would join in on that maybe we can use bootstrap and make it look a bit more modern full stop.

[johnnyshields]

@CloCkWeRX I think this is a reasonable request, it would certainly help my sales guys. IMHO we should look at stripping out the current CSS and replacing with Bootstrap 4. (#695)

[imkarthikk]

@johnnyshields I agree. Bootstrap 4 is super good, and we can try to bring in a light-weight Gulp support as well, to see if we can process SAAS or SCSS better with FatFree's backend. I stopped working on it for sometime, to focus on my job. But I have some free time now to take this up.

[saravanabalagi]

How about bulma instead of bootstrap?

[johnnyshields]

My two cents, rather than doing a facelift on Rails I think we should start a new project (or new major version) where we completely re-write the frontend in React and convert the Rails server to an API (objects via JSON). This is obviously much more work but I think would be really worth it in the long-run--both better performance and way easier to maintain.

My company is using FFCRM in production and I'd be open to contributing some development resources to this if others would join in as well.

[johnnyshields]

If we were to go with React I really like Atlaskit

[WMPayne]

If you're going to consider a front-end rewrite, it's certainly worth considering using Vue (+ Bulma or similar) over React. Vue tends to work much better with Rails backends, and is gaining a lot of ground over React. Either way, I'd be happy to help contribute to a new major version as well.

[saravanabalagi]

@johnnyshields +1; It's definitely worth rewriting API only backend and having a react redux frontend. We can choose Vue, but we can easily port react to react native for mobile apps at a later stage. I'm not so familiar with Vue, is there any such possibility in Vue as well?

[johnnyshields]

Looking objectively React is much more popular in terms of jobs and number of developers, and it's the gold standard of JS frameworks. I don't see any reason why React can't work well with Rails--especially MobX (instead of Redux) seems to work pretty well.

https://medium.com/@TechMagic/reactjs-vs-angular5-vs-vue-js-what-to-choose-in-2018-b91e028fa91d

[WMPayne]

I have a larger production site using React, and experience using React Native and Vue as well. I would certainly go with Vue for new projects. Although you're right, that many jobs and current projects use React (I do), I quit using it for new development. In the end I think it's almost entirely personal preference, and that's why I stated I'd prefer Vue. Ultimately, it's up to you (maintainers).

As per the article you referenced conclusion:

For a real engineer, there is no substantial difference which framework to choose, because it just takes some time to get used to the new one. In our company, we grow expertise in mostly ReactJS and Angular 2/4/5, but Vue.js is also on board. Every framework has its own pros and cons, meaning that there should be just a right choice for every single case during the product development.

Porting to React Native is not nearly as straightforward as it might seem, by the way, since it's not absolutely portable. Yes, you can reuse components and such, but it's unlikely you'll get much value out of it (at least, when I've done it, it wasn't super helpful).

Regardless, API backend is definitely a good idea.

[johnnyshields]

I'm the CTO of company with 20 devs and to be honest I haven't gotten deeply involved in any frontend framework. We use Ember JS and have been switching for React. My only concern for open-source projects like this is ease of other community members to getting involved, and for that React seems like a clear winner that isn't going away anytime soon. (Ember JS for example is a dying breed...)

[WMPayne]

Makes sense. React definitely isn't going to die out any time soon.

That being said, having an "API only" backend would allow for multiple front-ends if people wanted to develop for a different front end or a custom solution (easier integration with some other front end they have or similar).

[stanleylhs]

Sorry for the prolonged inactivity. Last time (years ago) when I talked with @steveyken it seems that we do have a old API backend already in place? Or are those code gone? I need to check the codebase again to see what we have.

I would be definitely up for a Vue/React rewrite. I have connections with the Hong Kong Vue.js meetup group, might be able to recruit for more volunteers to join this project if we decide to side with Vue.

[WMPayne]

I don't have any experience with this, but apparently NativeScript exists for using various JS frameworks (including Vue) that might be another factor if porting to mobile apps is important: https://www.nativescript.org/

[adamlfoater]

Hi all, I came across this crm and am looking for developers who can help me customise a version for my own needs. Can anyone help whilst at the same time improving FatFreecrm for others?

[CloCkWeRX]

I've raised some more specific cards around an incremental migration to bootstrap #913 #914 #912 #911

Ideally, this gives the bare minimum mobile UX of appropriate font sizes and focus on the relevant entity, lists, etc.

For now, I'm keeping the scope as small as possible, so we can do a small slice at a time - so React or a similar framework is probably out of the equation for the short term.
Hopefully the end result is something mostly workable on mobile, with a few rough edges; and if we do decide to refactor to something more SPA like the barriers are lower to take an isolated section and migrate it.