Merge pull request #2058 from OffchainLabs/image-zoom-in-feature

Image zoom in feature

Author: anegg0

arbitrum-docs/for-devs/third-party-docs/Particle/particle.mdx

@@ -6,6 +6,8 @@ sme: TABASCOatw
 sidebar_label: 'Particle Network'
 ---
 
+import ImageZoomComponent from '@site/src/components/ImageZoom';
+
 :::info Community member contribution
 
 Shoutout to [@TABASCOatw](https://github.com/TABASCOatw) for contributing the following [third-party document](/for-devs/third-party-docs/contribute)!
@@ -37,7 +39,7 @@ Given its modular architecture, developers have the liberty to choose which of t
 
 The user flow with Particle Network begins with social logins (using either a custom authentication or preset login methods provided by Particle Network), which leads to the generation of an EOA through MPC-TSS. This EOA is then used as a Signer for a smart account implementation that best fits the needs of the application in question (natively, this means a choice between SimpleAccount, Biconomy V1/V2, Light Account, and Cyber Account). A visualization of this process can be found below:
 
-![](https://i.imgur.com/qfEpjgz.png)
+<ImageZoom src="https://i.imgur.com/qfEpjgz.png" alt="Particle Network User Flow" />
 
 ---
 
@@ -126,7 +128,7 @@ export const ParticleConnectkit = ({ children }: React.PropsWithChildren) => {
 };
 ```
 
-This code sets up Particle Connect with a configuration for wallet authentication and blockchain interactions on Arbitrum Sepolia. It includes social logins and traditional Web3 options through WalletConnect and enables Account Abstraction (AA) with a `SimpleAccount` instance version 2.0.0. The configured `ConnectKitProvider` component then wraps the app’s content, making this configuration available.
+This code sets up Particle Connect with a configuration for wallet authentication and blockchain interactions on Arbitrum Sepolia. It includes social logins and traditional Web3 options through WalletConnect and enables Account Abstraction (AA) with a `SimpleAccount` instance version 2.0.0. The configured `ConnectKitProvider` component then wraps the app's content, making this configuration available.
 
 ## Integrate Particle Connect in Your App
 
@@ -164,7 +166,7 @@ export default function RootLayout({
 
 With your project set up, dependencies installed, and Particle Connect configured, you can start building in the `page.tsx` file.
 
-In `page.tsx`, you’ll define the core features: login flow, data visualization, transaction handling, and the UI.
+In `page.tsx`, you'll define the core features: login flow, data visualization, transaction handling, and the UI.
 
 ### Connecting the Wallet
 

arbitrum-docs/how-arbitrum-works/02-transaction-lifecycle.mdx

@@ -7,6 +7,8 @@ user_story: As a current or prospective Arbitrum user, I need to learn more abou
 content_type: get-started
 ---
 
+import ImageZoom from '@site/src/components/ImageZoom';
+
 This section explores the various methods users can employ to submit transactions for inclusion on the <a data-quicklook-from="arbitrum">Arbitrum</a> chain. We discuss the different pathways available—sending transactions to the <a data-quicklook-from="sequencer">Sequencer</a> or bypassing it by submitting transactions through the <a data-quicklook-from="delayed-inbox">Delayed Inbox</a> contract on the <a data-quicklook-from="parent-chain">parent chain</a>. By outlining these options, we aim to clarify how users can interact with the network, detail the processes involved in each method, and identify the modules responsible for handling these transactions. This overview will enhance your understanding of the initial steps in Arbitrum ecosystem's <a data-quicklook-from="transaction">Transaction</a> lifecycle and prepare you for a detailed exploration of transaction inclusion mechanisms in the subsequent sections.
 
 The first subsection, [Submitting Transactions to the Sequencer](#submitting-transactions-to-the-sequencer), presents four different methods users can utilize to send their transactions to the sequencer: via Public RPC, Third-Party RPC, Arbitrum Nodes, and the Sequencer Endpoint. Transactions sent through the first three pathways will route through our Load Balancer before reaching the sequencer. In contrast, the Sequencer Endpoint allows transactions to bypass the Load Balancer and be sent directly to the sequencer.
@@ -15,7 +17,11 @@ The second subsection, [Bypassing the Sequencer](#bypassing-the-sequencer), desc
 
 This diagram illustrates the various pathways for submitting transactions to the Arbitrum chain. It highlights the options for sending transactions through the sequencer or bypassing it and using the delayed inbox contract on the parent chain.
 
-![600px-img](../bold/assets/transaction-lifecycle.svg)
+<ImageZoom
+  src="/img/transaction-lifecycle.svg"
+  alt="Transaction lifecycle diagram showing various pathways for submitting transactions"
+  className="img-600px"
+/>
 
 ## Submitting transactions to the Sequencer
 
@@ -45,7 +51,11 @@ The Sequencer Endpoint is the most direct method for users looking to minimize d
 
 The diagram below shows different ways to submit transactions to the sequencer:
 
-![500px-img](../assets/submit-tx-to-sequencer.svg)
+<ImageZoom
+  src="../assets/submit-tx-to-sequencer.svg"
+  alt="Submit transaction to the Sequencer"
+  className="200px-img"
+/>
 
 ## Bypassing the Sequencer