InstaPy GUI

[timgrossmann]

One of the most important technical things is to have a new GUI tool for users that don't want to work with the command line/code editor to configure their InstaPy. To keep up with the changes of InstaPy, this time it has to be based on a simple JSON file (API.json) describing each available feature. I think https://github.com/ahmadudin/electron-instaPy-GUI was a good job, just not built for much compatibility with the quickly evolving InstaPy.

Advantages of this feature:

• Easy usage for people that are not to familiar with code
• More convenient and attractive to new users
• Good way to bundle and at some point deliver one single tooling.

Possible ways of achieving this while keeping control:

• Use and extend https://github.com/ahmadudin/electron-instaPy-GUI (or at least learn from the problems with it)
• Writing a completely new GUI application that will use the API.json file to dynamically construct the feature elements upon start.
• Webpage that gives the users all the possibilities and is familiar once people used on of the paid services out there

Bountysource this Issue

---

Feel free to comment with adjustments and improvements

[uluQulu]

That's a real deal 🍫 @timgrossmann
Could be great to see it happen 😁

[sionking]

Even a console with an exit button will be good

[lucanello]

I really like the idea of a GUI however there should be a possibility to start the script remotely on a server. That's why I would prefer a web front-end which serves all user needs instead of a cross-platform single instance application which is meant to run locally on a computer. The web front-end could have the possibility to enter the server IP and login data so even unexperienced users would only have to upload the web front-end files to a webserver (and connect to an InstaPy instance which runs remotely on a server). This way we could deploy always-up-to-date InstaPy servers with single-user IPs.

[Tkd-Alex]

I think the GUI is a good idea but, honestly I think the best things to do are:

• Create rest api for manage all InstaPy function. (and make easily development external service)
• Use only one dashboard for analytics and create new scripts.

[timgrossmann]

@lucanello @Tkd-Alex I absolutely agree on this points, thank you very much for sharing!

[GabrieleCalarota]

Also agree with @lucanello and @Tkd-Alex, a Web Application could solve all the Cross-Plattform issues and remote running on servers mentioned by @lucanello. To do so we need api to manage InstaPy function and a web interface to customize the script.
I can work at it but would appreciate some bounty reward too for a big feature like this!

[Tkd-Alex]

I can help too! :+1:
At the moment I have Instapy running on my VPS, managed by my Telegram-Bot and monitored by the dashboard :confused:

We could use the same logic of my Telegram-Bot and do something with Flask.

[GabrieleCalarota]

Also I think if we agree to move this way that this should be splitted into 2/3 feature request:

• API handling
• Front-end interface
• Remote server managment, settings, ..etc

What do you think?
@timgrossmann

[timgrossmann]

@GabrieleCalarota @Tkd-Alex Sounds really good, let me include the core team into the discussion and get back to you.
(maybe we can move the discussion here, too)
@converge @uluQulu @sionking what are your thoughts about this?

I think having a web interface will ease things up.

The only problem I see at the moment will be how people "download and start" the frontend when a server has to be started and browser window with some given url has to be open-end.
It kind of sounds a little bit inconvenient to be honest.

What would your suggestions be for this?

[converge]

I was working on a similar idea:
http://github.com/converge/duffgram

But it's time/server/money consuming, the API has a coast per month (server/bandwidth), this is a RESTful API I was testing: https://gist.github.com/converge/4a9e45f551ab3b9dacad0b278f8bf421

Long story short... the idea is good, but it's a lot of work.

The other point is that a part of the InstaPy users have issues to install it the way we have it today, adding more layers to the project, maybe will increase the difficulty to install it.

This is just a general thought to make us think deeper about it.

[timgrossmann]

@converge Is right, making InstaPy less error prone and available in an easier manner is more important at the moment.
Still a good thing to discuss what approach we'll be taking with this.

Soving the chromedriver issue and being able to finally pusblish InstaPy to PyPi should be the first problem to tackle.

[uluQulu]

Hi all

After reading @lucanello's post, it made me think cos he has outlined very good points.
Web interface ⚔ Desktop app 😉

And in that point, @GabrieleCalarota follows and wills to implement it and I believe he can do it greatly as I saw his work already.
@sionking also liked a Web interface [to be implemented] to configure InstaPy usage back then, not sure now.

Apart from @timgrossmann's point on its possible inconvenience [that I also agree of] and @converge's point on its complexity [that I agree], I have other points.

@lucanello has solid points that we need Web interface for the server-side people. Alright, but note that this is a general-purpose application and a solution should satisfy the biggest portion of users and I think, most of the users are desktop users with fairly less computer knowledge.
And thinking the day InstaPy grows, at least, more than 70% of the users will be of that kind.

Okay, knowing that, let's compare.
W = Web interface;
D = Desktop app;

• W can never bring smoothness, speed, efficiency of D;
• W is prone to crash easily [not a problem?];
• W will cause troubles on long runs due to memory handling;
• W usage will look non-friendly and it will lag easily;
• W will be poor and can never be rich cos of its nature;

About [a good] D:

• D will cost 10 times bigger implementation care;
• D can also support other servers 😉 as @lucanello thinks why we need W;
• D will be one-time implementation and with a documentation on long-time modification style at ease;
• D can support any platform;

But if you will write D at Electron (_or such_), I think W could be much better 😀
Please, feel free to write a W as you wish, since D and W can survive together, too 🤝🏼
I wish I could write D, but don't have enough free time to do it [yet].

I saw similar app with a W and it really was so uncomfortable (_think it was Zen-promo_).
There are many other points to compare D vs W that I won't dive into. It's just my point on it.

Just an addition, Adobe try to push people to use Photoshop's W whilst labeling its D as the '_classic version_' and MS did similar with Office 365.
As their W is not even close to be comparable with their D at any costs, do they think that one day W will fully replace D?
But it also is understandable cos with W they fight with the pirates well 😄

---

_{Thanks @timgrossmann for 🎤 mentioning.}

Cheers 😁

[converge]

2018 is the year I realized that the right use of emoticons is an important part of communication
+1 point to @uluQulu the master of emoticons 😄

[timgrossmann]

@uluQulu Haha, thank you for the write-up.
You forgot that D, in most cases, will be ugly 🙈 😜

beautifulweb

[lucanello]

@uluQulu Thanks for your detailed explanation.
The main reason why I would prefer a web interface over a desktop application is the fact, that InstaPy and its instances are quite time-consuming. If you plan to use InstaPy and don't want to have the risk of being shadow-banned or blocked, you will end up leaving your PC on the whole time in order to see an effect.

I don't know about your settings, but one of my accounts is using this setup:

• 130-150 likes
• 0 following
• 20-30 comments
• 40-60 already liked
• 20-30 not liked because they were inappropriate
• 20-30 not followed because they were inappropriate
  and it takes about 95 minutes each time. I am already using this low configuration without following anyone so I can save time and don't have to unfollow everyone. But in my case I leave this instance running 3 times a day so I can see any improvements with my account (this point is no argument because every account needs to be studied separately).

So to sum up, an ordinary InstaPy setup is doing 165 actions in 95 minutes which are about 1,7 actions per minute.
To see any effect you have to multiply by three which means that I would have to leave my notebook on for 285 minutes (which are about 5 hours).

In my opinion this would be a total power wastage, especially when you don't use a ~8W Macbook Pro like me but a full gaming or workspace rig with 400W+ power consumption.

Another point is modularity. Building a desktop interface means a lot of work when thinking about compatibility. This will mean that not only the interface itself has to be adapted to every platform (even if using Electron or else), but every module or extension has to be developed, configured and tested for each single platform aswell.
Additionally it won't be usable on mobile phones. Even with such a mobile-oriented network like Instagram this will be a huge problem since most of the potential users are primarily using a mobile phone as I believe.

All in all I think InstaPy is a classical server application which shouldn't be deployed on home computers, workstations or gaming machines.

Thanks for reading, I hope I didn't tl;dr
Greetings
Luca

[uluQulu]

Glad to read your point of view. @lucanello.
Unlike you, I have a slow laptop (_1.40 GHz_) on which I run it differently, mostly nights and sometimes evenings, no scheduling, no threading, no cron job.
Well, it's another story and I don't recommend my style to anybody.
But it's really difficult to predict the general use case without thorough analytical data or feedback.

---

I find no problem in preparing a cross-platform fluent D which would consume almost no any extra computer resources and be many times faster than W.

But one specific case you have outlined I find difficult is,
"_Additionally it won't be usable on mobile phones._"
which really is a problem.

Making a desktop app and making a mobile app are 2 different jobs.
Mostly cos of average display size, mobile app must be designed differently.
In that case, W stands clear.
But making a D and offering mobile phones a light-weight dashboard will be the best.
Cos, basically, you cannot provide the same set of advanced capabilities inside a small display mobile phone which does not have a keyboard.
Instead, mobile phones are good to view some stuff and switch others on/off.

Well, well, well.. I really think most of the community want to implement a W as I heard till now.
And since I can't write D at the moment, I can't say more 🙂

---

Good luck 😁

[timgrossmann]

@lucanello @uluQulu Thank you for the discussion, guys!
I like your reasoning @lucanello

I think what we've talked about before is this approach:

• Build an API for InstaPy that allows us to "start a server" and send request which then triggers the different methods of InstaPy

• Create (update) the API.json file that contains the definition for each available method => will be used for the frontend to know what can be configured. In the end this should be created dynamically based on the elements in the API.json

This will allow us to enable several things.

1. People will be able to build their own frontends if they want to with any language they are interested in (already got a question whether it has an API because he wanted to build a PHP interface)

1. Create a standalone instapy frontend that users can use by default
   
   
   
   • maybe just enter the url and port of your virtual server and you're able to set it up from your local machine once it's installed on that server
   
   
   • let people download a "bundle" that automatically starts a local server so people can set it up and run it on their local machine (mostly useful for people that have no clue about servers etc.)
   
   

I think this approach gives us the most modularity and should allow us to extend InstaPy from there.
What do you think?